Most organisations run three identity estates, for employees, customers and machines, that grew separately and now share infrastructure, administrators and attack paths without anyone having drawn them as one system. This guide sets out an end-to-end identity reference architecture covering workforce identity, customer identity (CIAM) and non-human identities (NHIs) such as service accounts, workload identities, API keys and AI agents. It names the components in each layer, the trust boundaries between them and the design decisions that matter most, drawing on NIST SP 800-207 and 800-207A, NIST SP 800-63-4, the CISA Zero Trust Maturity Model, Microsoft's enterprise access model and the SPIFFE specifications. It is for identity architects, security architects and platform teams. It does not repeat the deep guides on each component; it links them.
Key takeaways
- The identity provider is the control plane. Microsoft's enterprise access model puts centralised identity systems in the control plane, which controls every plane below it, so IdP administration deserves the strongest protection in the estate.
- Three populations, one set of layers. Workforce, customer and non-human identities all need authoritative sources, stores, authentication, authorisation, governance and detection, but the components and assurance levels differ.
- Separate what attackers would chain. Customer and workforce directories, production and non-production trust domains, and admin and user access paths should not share an administrator or a trust anchor.
- Identity replaces the network as the segment. NIST SP 800-207A moves access control from IP addresses and subnets to application, service and user identities, which only works if every workload has a verifiable identity.
- Machines are the largest and least governed population. The architecture must issue NHIs short-lived, attested credentials through federation, not distribute long-lived secrets, and must give every NHI an owner.
The reference layers
The table is the core of the architecture: each row is a layer, each column a population. Use it as a checklist when mapping your current estate.
| Layer | Workforce | Customer (CIAM) | Non-human |
|---|---|---|---|
| Authoritative source | HR system for employees; vendor management for contractors | Self-registration, with identity proofing where required | CMDB, cloud accounts, code repositories, CI/CD and agent registries |
| Identity store | Enterprise directory (on-premises AD and cloud directory) | Dedicated customer directory or CIAM tenant | Cloud IAM, service principals, Kubernetes service accounts, SPIFFE trust domains |
| Provisioning | Joiner-mover-leaver workflows, SCIM to SaaS | Just-in-time on registration, progressive profiling | Infrastructure as code, workload attestation, automated issuance |
| Authentication | Phishing-resistant MFA, passkeys, device-bound sessions | Passkeys, risk-based MFA, assurance chosen per 800-63B-4 AAL | Federated workload identity (OIDC tokens, X.509-SVIDs), mTLS; secrets only where unavoidable |
| Federation and SSO | SAML and OIDC to SaaS and internal apps | OIDC to customer apps, social login, B2B organisations | Workload identity federation to cloud, token exchange between domains |
| Authorisation | RBAC and ABAC through groups and access packages; conditional access | Consent, scopes, fine-grained app authorisation, delegated admin for B2B | Least-privilege roles, OAuth scopes, policy at the gateway or service mesh |
| Privileged access | PAM, just-in-time elevation, privileged access workstations | Customer support tooling with audited impersonation | Vaulted, rotated or dynamic credentials; no human use of service accounts |
| Governance | IGA: access requests, certifications, separation of duties | Consent records, account deletion and data subject rights | Ownership, inventory, recertification, decommissioning |
| Detection | ITDR on sign-in and directory changes | Account takeover and fraud detection | Anomalous token use, secrets scanning, ISPM posture checks |
See the IAM and IGA Basics for definitions of each component.
Planes, pathways and trust boundaries
Microsoft's enterprise access model divides the estate into a control plane (centralised identity systems), a management plane (IT functions that manage workloads and infrastructure) and a data and workload plane (applications and data). It replaces the Active Directory tier model: tier 0 becomes the control plane, tier 1 splits into management and workload planes, and tier 2 splits into user access and application access. Access reaches these planes through three pathways: user access, application (API) access and privileged access. The model's requirement for consistent enforcement across users, admins, APIs and service accounts is the reason a reference architecture must treat NHIs as first-class.
| Trust boundary | What crosses it | Design decision | Control |
|---|---|---|---|
| Control plane to everything | IdP admin actions, federation trust, sync accounts | Which accounts can administer the IdP, and from where | Dedicated admin accounts, phishing-resistant MFA, PAWs, change alerting |
| On-premises directory to cloud IdP | Synchronised identities, password hashes or pass-through authentication | Sync scope and whether privileged on-premises accounts are synchronised | Cloud-only admin accounts; treat sync servers as control plane |
| Workforce to customer estate | Support staff access to customer accounts | Separate tenants or a shared one | Separate tenants and admins; audited, time-limited support access |
| Production to non-production | Test tenants, test apps, shared credentials | Whether any trust or app consent spans them | Separate trust domains, no cross-environment app permissions |
| Organisation to SaaS and partners | OAuth grants, SAML trusts, API keys | Who can consent to third-party apps | Admin consent workflow, scope review, token revocation path |
| Workload to workload | Service calls, tokens, certificates | Network-based trust or identity-based trust | mTLS with workload identity, identity-tier policy (SP 800-207A) |
| Agent to tools and data | Delegated user tokens, agent credentials | Whether the agent acts as itself, on behalf of a user, or both | Distinct agent identity, token exchange with narrowed scopes, approval gates |
The Microsoft Midnight Blizzard breach crossed two of these boundaries at once: a password spray on a legacy test tenant account without MFA led to a legacy test OAuth application with elevated access to the corporate environment. See the Federation and Trust Relationships Guide.
Workforce identity path
- Source to store: HR events drive joiner-mover-leaver automation into the directory, then SCIM to SaaS. Contractors come from a vendor system with an end date. See the Joiner-Mover-Leaver Guide and the SCIM Provisioning Guide.
- Authentication: phishing-resistant MFA for all staff and mandatory for administrators; the help desk reset process is part of authentication, because it issues credentials. The MGM Resorts breach is the reference case: the attackers say a help desk call led to administrator privileges in the Okta and Azure tenants. See the Phishing-Resistant MFA Guide.
- Policy decision and enforcement: NIST SP 800-207 separates a policy engine that decides, a policy administrator that sets up the session, and a policy enforcement point in front of every resource. In practice, conditional access in the IdP is the first PEP; application gateways and identity-aware proxies are others. See the Conditional Access Guide.
- Privileged access: separate admin accounts, just-in-time elevation through PAM and dedicated workstations for control plane administration. See the Privileged Access Management Guide.
- Break-glass: at least two emergency accounts excluded from normal policies, monitored for any use, with credentials held offline. See the Break-Glass Account Guide.
Customer identity path
- Separate tenant: run CIAM in its own tenant or product, with its own administrators. A compromised workforce admin should not be able to export customer identities, and a customer-facing vulnerability should not reach the workforce directory.
- Assurance by transaction: SP 800-63-4 (final, July 2025) defines identity assurance (IAL), authenticator assurance (AAL) and federation assurance (FAL) levels. Map each customer journey, for example browsing, payment, changing bank details, to the level it needs, then apply step-up authentication only where required. See the NIST SP 800-63 Guide.
- B2B customers: model each business customer as an organisation with delegated administrators and its own federation to your platform, rather than as a list of individual users. See the B2B CIAM Organisations Guide.
- APIs and apps: customer-facing apps are OAuth clients; mobile and single-page apps are public clients and need PKCE and a backend for frontend where possible. See the OAuth 2.0 and OpenID Connect Guide.
- Detection: credential stuffing, account takeover and fake account creation signals feed fraud tooling, not only the SOC.
See the Customer IAM (CIAM) Guide for depth.
Non-human identity path
NHIs outnumber people in most estates and are issued by many systems: cloud IAM, Kubernetes, CI/CD, SaaS admin consoles and now agent platforms. The architecture's job is to make them issued, attested, short-lived and owned.
- Workload identity as the default: SPIFFE defines a workload identity as a URI such as spiffe://acme.com/billing/payments, proven by an X.509 or JWT SVID obtained from a Workload API, with keys that are short-lived and rotated automatically. SPIFFE recommends X.509-SVIDs where possible because tokens can be replayed, and separate trust domains for environments such as staging and production. See the SPIFFE and SPIRE Guide and the WIMSE Workload Identity Architecture Guide.
- Federation instead of secrets: CI/CD and cross-cloud access use OIDC workload identity federation with tight subject conditions, rather than stored access keys. See the Cloud Workload Identity Guide.
- Secrets where unavoidable: third-party API keys and legacy service account passwords live in a vault, are issued dynamically where the target supports it and rotate automatically. See the Dynamic Secrets and Ephemeral Credentials Guide.
- Identity-tier policy: SP 800-207A describes policies based on application and service identities as well as network parameters and user identities, enforced by API gateways, sidecar proxies and application identity infrastructure.
- AI agents: give each agent its own identity, link it to the user it acts for, and narrow delegated tokens by exchange rather than passing user tokens through. See the Agentic AI Identity Guide.
- Governance: every NHI has a human owner, a purpose, an expiry or review date and a decommissioning trigger. See the Non-Human Identity (NHI) Guide.
Decision guidance
| Decision | Option A | Option B | Choose A when / B when |
|---|---|---|---|
| Workforce and customer identity platform | Shared vendor, separate tenants | Separate products | A for smaller teams wanting one skill set; B when CIAM scale, branding or fraud features dominate. Avoid one shared tenant in either case |
| Hybrid directory | Keep on-premises AD as source | Cloud directory as source, AD for legacy only | A while legacy apps depend on Kerberos; plan B as apps modernise |
| Workload identity | Cloud-native identities per provider | SPIFFE trust domains across clouds | A for single cloud; B for multi-cloud, on-premises or service mesh estates |
| Authorisation | Per-application roles | Central policy decision point (policy as code) | A for few apps; B when many services need consistent rules and audit |
| Agent identity | Agents run as delegated user | Agent identity plus delegation | A only for read-only, low-impact assistants; B for anything that writes or acts autonomously |
Small versus large organisations: a small organisation can deliver most layers with one cloud IdP (two tenants), a secrets manager and built-in logs. Large organisations need IGA, PAM, ISPM and ITDR as distinct capabilities, plus an architecture authority to keep the boundaries above from eroding. Record each choice as an architecture decision record.
How to implement
- Map the current estate against the reference layers table: every directory, IdP, tenant, sync server, vault, and every system that issues NHIs.
- Protect the control plane first: dedicated admin accounts with phishing-resistant MFA, break-glass accounts, alerting on IdP configuration and federation changes.
- Cut the dangerous boundaries: remove cross-environment app permissions, retire legacy test tenants, stop synchronising privileged on-premises accounts to the cloud.
- Pilot workload identity federation for one CI/CD pipeline and one service-to-service flow, in parallel with existing secrets, then remove the secrets after a clean month.
- Bring NHIs into governance: inventory, owners and recertification, starting with the most privileged.
- Roll out detection across all three populations into one place, so an attack that crosses boundaries is visible as one story.
- Rollback: keep previous authentication paths available but monitored during each cut-over, with a documented switch back, and remove them on a fixed date.
Detection and measurement
- Log sources: IdP sign-in and audit logs, directory change logs, cloud IAM and role assumption logs, vault access logs, CIAM events and agent tool-call logs. See the Identity Telemetry Requirements Guide.
- High-value alerts: new IdP administrators, new federation trusts or signing certificates, MFA method resets for admins, consent to high-privilege apps, NHI use from new locations.
| Metric | What good looks like |
|---|---|
| Control plane admins with phishing-resistant MFA | 100 per cent |
| Workforce and customer identities sharing a tenant or admin | Zero |
| NHIs with a named owner | Rising to 100 per cent, privileged first |
| Workloads authenticating with federated or attested identity rather than stored secrets | Rising quarter on quarter |
| Apps and trusts spanning production and non-production | Zero |
| Median time to revoke all credentials of a departed employee or retired workload | Hours, not days |
Framework mapping
| Framework | Reference | Layer |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 to PR.AA-05 | Identity management, proofing, authentication, assertions, access permissions |
| NIST CSF 2.0 | DE.CM-03 | Detection across populations |
| NIST SP 800-53 Rev. 5 | AC-2, AC-3, AC-6, IA-2, IA-4, IA-5, IA-8, IA-9 | Accounts, enforcement, least privilege, authentication of users, non-organisational users and services |
| NIST SP 800-207 and 800-207A | PE, PA, PEP; identity-tier policies | Authorisation and workload-to-workload trust |
| NIST SP 800-63-4 | IAL, AAL, FAL | Assurance for workforce and customer journeys |
| CISA Zero Trust Maturity Model v2.0 | Identity pillar | Maturity target for authentication, identity stores, risk assessment and access management. See the CISA Zero Trust Maturity Model Guide |
| ISO/IEC 27001:2022 Annex A | 5.15 Access control, 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, 8.2 Privileged access rights | Policy and management controls |
Common failure patterns
- Forgotten tenants and test apps: legacy environments with live trust into production, as in the Midnight Blizzard breach.
- Help desk as a bypass: strong MFA undone by a reset process that verifies callers with public information.
- Shared admin across workforce and CIAM: one compromised admin exposes both populations.
- Sync servers outside the control plane: directory synchronisation hosts managed like ordinary servers despite controlling identity.
- NHIs outside the architecture: service accounts and API keys created per project with no issuance path, owner or expiry.
- Agents riding user tokens: agents given a user's full delegated access instead of their own narrowed identity.
Practitioner checklist
- Draw your estate against the reference layers, all three populations, on one page.
- List every account that can administer an IdP, directory or sync server, and enforce phishing-resistant MFA and dedicated workstations for them.
- Separate CIAM from workforce identity at tenant and admin level.
- Remove every trust, app permission or credential that spans production and non-production.
- Make workload identity federation the default for CI/CD and service-to-service authentication.
- Give every AI agent its own identity linked to its delegating user.
- Assign an owner and review date to every privileged NHI.
- Send IdP, directory, cloud IAM, vault and CIAM logs to one detection platform.
- Record each major architecture choice as a decision record.
Standards and references
- NIST: SP 800-207 Zero Trust Architecture
- NIST: SP 800-207A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
- NIST: SP 800-63-4 Digital Identity Guidelines
- CISA: Zero Trust Maturity Model
- Microsoft Learn: Enterprise access model
- SPIFFE: SPIFFE Concepts
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: NIST SP 800-207 Zero Trust Architecture Guide · Identity Provider and SSO Security Guide · Non-Human Identity (NHI) Guide · ISPM Guide