IAM Solution Design: [Organisation or programme name]

Solution design for workforce identity and access management (IAM): authoritative identity sources, assurance levels, authentication and passkeys, single sign-on and federation, joiner/mover/leaver lifecycle, authorisation model, privileged access, access reviews, workload and machine identities, logging and the migration plan. Assurance levels follow NIST SP 800-63-4 Digital Identity Guidelines (final, July 2025: SP 800-63A-4, 63B-4 and 63C-4). Protocol choices follow SAML 2.0, OpenID Connect Core 1.0, the OAuth 2.0 Security Best Current Practice (RFC 9700), SCIM 2.0 (RFC 7643 and RFC 7644) and W3C Web Authentication Level 3. Zero trust alignment follows NIST SP 800-207. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Scope, drivers and principles
2. Current state and target overview
3. Identity sources and authority
4. Assurance levels
5. Authentication and passkeys
6. Federation and single sign-on
7. Identity lifecycle: joiner, mover, leaver
8. Authorisation model
9. Privileged access
10. Access governance and reviews
11. Service, workload and machine identities
12. Logging, monitoring and identity threat detection
13. Resilience and operations
14. Migration and rollout plan
15. Requirements traceability and acceptance
16. Risks and decisions
17. Glossary and references

1. Scope, drivers and principles

1.1 Scope

1.2 Drivers

1.3 Design principles

2. Current state and target overview

2.1 Current state summary

Record, for each area, the current state and the main gap: directories and forests (for example two on-premises forests after an acquisition, so no single join key), authentication methods (for example password plus SMS for remote access only), SSO coverage (for example 120 of 410 applications federated), provisioning (for example 70% manual tickets, so orphaned accounts), privileged access (for example shared vaulted passwords with standing rights) and reviews (for example an annual spreadsheet). Quantify each gap; the numbers become the baseline for the acceptance criteria in section 15.

2.2 Target logical architecture

The HR system and the contractor register feed the governance tool, which drives the directory and application accounts; the identity provider authenticates users and asks the policy decision point for each access decision. The policy decision and enforcement split follows NIST SP 800-207; the wider zero trust roadmap lives in Zero Trust Architecture Plan (security/zero-trust-architecture).

2.3 Capability to product mapping

Record each product choice as an ADR in the Architecture Decision Log (architecture/architecture-decision-log); use the Build vs Buy Analysis (architecture/build-vs-buy-analysis) when the choice is contested.

3. Identity sources and authority

3.1 Populations and authoritative sources

3.2 Attribute authority

3.3 Identifier and correlation rules

• Assign one immutable identifier per human, independent of employment type, so that a contractor who becomes an employee keeps one identity history.
• Correlate existing accounts during migration using [employee number / verified email / manual match], and record every manual match with the approver.
• Never recycle usernames or email addresses within [Example: 24 months] of release.
• Store the federated subject identifier (NameID for SAML, sub for OIDC) per application so that a renamed user is not treated as a new person.

4. Assurance levels

4.1 Method

NIST SP 800-63-4 replaces a fixed assurance table with a digital identity risk management (DIRM) process: define the online service, assess the impact of failures, select initial identity, authentication and federation assurance levels, tailor them with compensating or supplemental controls, and evaluate continuously. Record each step for each application tier below, and keep the tailoring rationale, because auditors ask for it.

4.2 Assurance by population and application tier

5. Authentication and passkeys

5.1 Authenticator policy

5.2 Sign-in and step-up flow

The flow below shows a standard sign-in at AAL2 with a passkey; the same path with a higher requested authentication context gives step-up.

5.3 Session and reauthentication

SP 800-63B-4 gives upper bounds for AAL2 and AAL3 reauthentication; set your values at or below them and record any business exception.

5.4 Registration, recovery and help desk

• Bind the first authenticator during onboarding using a one-time enrolment code delivered through [manager / HR / in person], valid for [Example: 72 hours].
• Require every user to register at least two authenticators so loss of one does not force a help-desk reset.
• Help-desk recovery requires identity verification at the same IAL as enrolment (for example a video check against the HR photo plus manager confirmation), never knowledge questions alone.
• Log every recovery as a security event and notify the user on all registered channels.
• After recovery, revoke all sessions and refresh tokens and require re-registration of a phishing-resistant authenticator.

6. Federation and single sign-on

6.1 Protocol standards

6.2 Application onboarding tiers

6.3 Claims and attribute contract

Release the minimum attributes each application needs; record each release in the application's onboarding record.

7. Identity lifecycle: joiner, mover, leaver

7.1 Lifecycle flow

HR events drive every change; no human creates or deletes a standard account by hand.

7.2 Lifecycle service levels

7.3 Provisioning standards

• Use SCIM 2.0 (RFC 7643 schema, RFC 7644 protocol) for every application that supports it; check for RFC 9865 cursor pagination support on large tenants, and for RFC 9967 (SCIM profile for Security Event Tokens, which also adds optional asynchronous requests) where applications should emit or receive lifecycle events (section 12).
• For applications without SCIM, use governance connectors or scheduled reconciliation that reports accounts without a matching active identity.
• Disable before delete: deactivation preserves audit trails; delete after the retention period in the records schedule.
• Revoke refresh tokens and active sessions at disable time; SCIM deactivation alone does not end existing sessions in many applications.

8. Authorisation model

8.1 Model layers

For fine-grained or relationship-based decisions inside your own applications, use the patterns in Authorization service design (system-design/design-authorization-service) rather than pushing thousands of groups into tokens.

8.2 Role engineering rules

• Start from entitlement usage data (who uses what), then confirm with business owners; do not design roles top-down from the organisation chart alone.
• Cap business roles at [Example: one role per 30 people on average]; review roles with fewer than [3] members.
• Every entitlement has an owner, a description in business language, a risk rating and a review frequency.
• Requests outside a role need justification, an end date for high-risk items and approval by the entitlement owner.

8.3 Segregation of duties

9. Privileged access

9.1 Privileged access model

9.2 Administrative tiers

9.3 Break-glass accounts

• Keep [Example: two] emergency accounts per critical tenant, excluded from conditional access that depends on the IdP being reachable, but protected by hardware keys stored in separate safes.
• Alert on every sign-in to a break-glass account and review within one business day.
• Test the procedure every [Example: six months] and record the result in the Disaster Recovery Plan (ops/disaster-recovery-plan).

10. Access governance and reviews

10.1 Review campaigns

Use Access Review (ops/access-review) to record each campaign's findings, actions and sign-off.

10.2 Making reviews meaningful

• Show reviewers last-used dates, peer comparison and risk rating for each item; highlight outliers instead of listing everything equally.
• Pre-approve access that matches role rules and ask reviewers only about exceptions, so attention goes where risk is.
• Remove access automatically on "revoke" decisions and keep the fulfilment evidence with the decision.

11. Service, workload and machine identities

11.1 Non-human identity types

11.2 Rules for non-human identities

• Every non-human identity has a named human owner, a purpose, an expiry or review date and a record in the inventory.
• Interactive sign-in is disabled for service accounts.
• Scope permissions to one workload and one environment; never reuse a production identity in test.
• Detect secrets in code repositories and pipelines, and treat any found secret as compromised.
• For workload-to-workload trust inside the platform, see section 9 of PKI and Certificate Architecture (security/pki-certificate-architecture).

12. Logging, monitoring and identity threat detection

12.1 Events and retention

Send sign-in successes and failures, authenticator registration and recovery, lifecycle and provisioning actions, privileged elevations and session records, configuration changes to the IdP, directory and PAM, and workload token issuance to the SIEM. Example: keep [13] months searchable and [7] years archived where regulation requires, and keep privileged session recordings for [1] year. Retention must let you answer "who had access to system X on date Y" for the whole audit period.

12.2 Detections

Where applications and the IdP support it, exchange session and account events (session revoked, credential changed) using the OpenID Shared Signals Framework with CAEP and RISC event types, so that a disable at the IdP ends sessions everywhere quickly.

13. Resilience and operations

Assign the identity platforms a resilience tier in Resilience Tiering and HA/DR Design (architecture/resilience-tiering-ha-dr-design); they normally sit in the highest tier because everything else depends on them.

14. Migration and rollout plan

14.1 Waves

14.2 Cutover controls

• Run old and new authentication in parallel per application until the rollback window closes; switch by group, not by user.
• Communicate to users at least [Example: two weeks] before each change, with a self-service registration link and help-desk capacity planned for the peak.
• Use Cutover Plan (project/cutover-plan) for each wave's go and no-go and rollback steps.

15. Requirements traceability and acceptance

Carry non-functional requirements (availability, sign-in latency, provisioning throughput) from the NFR Catalogue (requirements/nfr-catalogue).

16. Risks and decisions

16.1 Risks

16.2 Decisions

17. Glossary and references

17.1 Glossary

17.2 References

Standard and licence note

Based on NIST SP 800-63-4 Digital Identity Guidelines (final, July 2025) and NIST SP 800-207, which are works of the US Government and not subject to copyright in the United States, and on the public specifications SAML 2.0 (OASIS), OpenID Connect Core 1.0 (OpenID Foundation), RFC 9700, RFC 9449, RFC 7643, RFC 7644, RFC 9865, RFC 9967 (IETF), W3C Web Authentication Level 3 and SPIFFE. Assurance levels are paraphrased in original wording; no specification text is reproduced. This template is original text written for this collection. Product names belong to their owners. Check the current official versions before use, because NIST publishes errata and the identity specifications continue to evolve. Template licence: MIT.