Identity
Establish the person or workload independently from any one application, then evaluate authority in the current organization context.
Identity chapterMulti-company trustTrust infrastructure for multi-company software
Federated Trust gives people, organizations, applications, and agents a governed way to establish identity, delegate access, and protect business secrets across company boundaries.
A neutral trust layer for people, agents, and the organizations they serve.
Start with your responsibility
Five roles, one trust model. Pick your role to see exactly what you own.
The platform model
Establish the actor, decide the authority, and protect the business material without collapsing those responsibilities into one system.
How they connect
Each boundary stays independent, then meets at a single governed exchange, so authority is always explicit and revocable.
Establish the person or workload independently from any one application, then evaluate authority in the current organization context.
Identity chapterKeep protected business material in a deployment and key-custody profile chosen for the organization.
Custody chapterSeparate software licensing from recorded, reviewable, and revocable access granted to people, apps, and agents.
Delegation chapterThe result
One governed exchangeThe interactive model
Follow one request across the model. Click a stage to see how each responsibility stays separate, and why the data plane always keeps final deny.
The three-step trust exchange
Three named steps. Each one hands the next a smaller, better-labelled artefact, never a blank cheque.
Authentication answers whether the presented credential belongs to an account. Nothing more.
The person, application, or agent receives a narrowly-attenuated grant. Recorded. Reviewable. Revocable.
The resource service applies local policy and retains final deny. No upstream claim can override.
Designed deployment profiles
Federated Trust is designed for managed, customer-controlled connected, and sovereign/offline data planes. These are not generally available offerings yet; every deployment requires a validated package and explicit key-custody, observability, update, recovery, and support responsibilities.
Profile
Managed profileThe designed provider-operated profile reduces operational burden while retaining tenant boundaries, explicit support access, and export responsibilities.
Required responsibilities
Who owns what
| Concern | Managed | Customer-controlled | Isolated |
|---|---|---|---|
| Key custody | Federated Trust | Customer | Customer |
| Observability | Provider baseline | Shared, customer-scoped | Customer |
| Support access | Explicit, logged | Explicit, logged | Off by default |
| Update cadence | Provider-scheduled | Customer-coordinated | Customer, signed only |
| Recovery evidence | Provider proof | Shared drill | Customer-owned drill |
Designed means the target architecture is approved, but it is not generally available until its deployment package and operating evidence are validated.
Program snapshot
00controls
Ready for pilot handoff
00controls
Active in production sandbox
00docs
Standards mapped to controls
Governing references
4 standardsImplementation coalition
Cross-disciplinary expertise for cloud delivery, data intelligence, regulated software, physical security, and platform engineering.
Frequently asked
Six questions that come up in every scoping call. Each answer is written to the same status labels the rest of the site uses.
The design does not require replacing an existing identity provider. Each integration must still document how a person or workload proves identity and how authority is evaluated in the current organization context.
The public documentation describes managed, customer-controlled, and isolated target profiles. They are designed shapes, not generally available offerings, and each still requires a validated deployment package.
Local final deny is a required design contract. Each deployment profile must prove its offline-policy, revocation, expiry, rollback, and secure-time behavior before claiming conformance during a partition.
Every public claim uses one of six labels: Implemented, Limited pilot, Designed, Planned, Independently validated, or Governing reference. Status is part of the claim.
Bounded capability delegation has limited-pilot code evidence. The target contract keeps agent identity separate and binds delegated authority to a specific audience, resource, action, purpose, and lifetime.
The preview-access page validates the required details and opens a structured email draft. Sending that draft starts a conversation about whether a bounded evaluation is appropriate.
The design does not require replacing an existing identity provider. Each integration must still document how a person or workload proves identity and how authority is evaluated in the current organization context.
Design invariant: identity may travel; authority stays narrow; every conforming data plane must retain final deny.
Federated Trust design invariant