A new identity provider becomes the front door to every application it federates, so the decisions made during rollout decide whether it removes risk or concentrates it in one tenant an attacker can own. This playbook covers rolling out a workforce identity provider (IdP) and single sign-on (SSO) platform as a product class: design and assurance decisions, standing up the tenant and its administrators, onboarding applications in waves, moving users onto phishing-resistant authentication, retiring legacy sign-in paths, and launching with testing and rollback. It is vendor-neutral and based on NIST SP 800-63-4, NIST SP 800-53 Rev. 5, CISA guidance, OWASP and IETF RFC 9700. It is written for IAM architects, identity engineering teams and the security leads who sign off the go-live. Product selection is covered in the IAM and IdP Buyer's Guide; steady-state hardening is in the Identity Provider and SSO Security Guide.
Key takeaways
- Protect the tenant before you populate it. Administrators, break-glass accounts and audit logging must be in place before the first application is federated, because every later control depends on them.
- Set assurance targets per population. Decide which users and applications need AAL2 or AAL3 and which federations need FAL2, then configure policy to match rather than to defaults.
- Onboard applications in risk-ordered waves. Start with low-risk pilots to prove the pattern, then move privileged and internet-facing applications early, not last.
- Close the old doors. SSO adds little if local passwords, legacy protocols and the previous IdP still accept sign-ins; plan their retirement as named milestones.
- Keep a way back. Every wave needs a tested rollback path and a break-glass route that does not depend on the new IdP.
Phase 0: scope, assurance and architecture decisions
Before configuration, agree what the IdP will be authoritative for and what assurance each population needs. NIST SP 800-63B-4 sets authentication assurance levels (AALs): at AAL2 verifiers must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for staff, contractors and partners; AAL3 requires a phishing-resistant authenticator with a non-exportable private key, which rules out syncable authenticators. NIST SP 800-63C-4 adds federation assurance levels (FALs), which describe how strongly assertions are protected between the IdP and each relying party (RP).
| Population or application | Target (NHI Mgmt Group recommendation) | Rollout implication |
|---|---|---|
| IdP administrators and other tier 0 roles | AAL3, device-bound phishing-resistant authenticator | Issue hardware authenticators before admin accounts are created |
| IT administrators, help desk, finance approvers | AAL2 phishing-resistant; AAL3 where policy demands | First user wave for passkeys or certificate-based authentication |
| General workforce | AAL2, phishing-resistant preferred | Allow a transitional method only with a retirement date |
| Contractors and partners | AAL2; federate to their IdP where trust is established | Trust agreement per partner, separate lifecycle owner |
| High-impact applications (finance, source code, production consoles) | FAL2: RP-initiated, single-RP audience, replay protection | Disable IdP-initiated sign-in for these applications |
Also decide in this phase:
- Authoritative source: which HR or directory system creates and disables identities, and how the IdP receives changes (SCIM, directory sync or both). See the SCIM Provisioning Guide and Directory Service vs Identity Provider.
- Protocols: OpenID Connect for new and modern applications, SAML 2.0 where the application only supports it, and a plan for applications that support neither. See LDAP vs SAML vs OIDC.
- Tenancy: separate production and non-production tenants with no shared administrators, signing keys or application registrations.
- Trust agreements: SP 800-63C-4 requires trust agreements even inside a single security domain, covering the subscriber population and the permitted IAL, AAL and FAL. A short internal record per federation is enough.
- Non-human identities: which service accounts and workloads will authenticate through the IdP and which stay with workload identity federation or a secrets manager. Do not let service accounts become hidden exceptions to user policy.
Phase 1: stand up and protect the tenant
The tenant is tier 0 from day one. In the advisory on Scattered Spider (AA23-320A), CISA describes attackers who, after taking over an account, added their own federated identity provider to the victim's SSO tenant and turned on automatic account linking, so they could sign in as any matching user and keep access after password changes. ATT&CK tracks this as T1484.002 Trust Modification. Build the protections in before anything depends on the tenant.
- Admin model: a small number of dedicated admin accounts, separate from daily accounts, each with an AAL3 authenticator (CIS Controls v8.1 safeguards 5.4 and 6.5; NIST SP 800-53 AC-6(5) and IA-2(1)). Split roles: policy, application registration, user support and read-only audit. Make high-impact roles just-in-time where the platform supports it. See the JIT Access Guide.
- Admin workstations: administer the tenant only from hardened devices. See the Privileged Access Workstations Guide.
- Break-glass accounts: two cloud-only emergency accounts with hardware authenticators, excluded only from the policies that could lock them out, alerted on every use and tested quarterly. See the Break-Glass Account Guide.
- Audit logging first: stream sign-in and admin audit logs to the SIEM before the pilot, with retention that covers your investigation window.
- Configuration as code: export or manage policies, application registrations and federation trusts through the platform's API or infrastructure-as-code tooling with peer review and drift detection (NIST SP 800-53 CM-3 and CM-6).
- Restrict trust changes: limit who can add identity providers, federation trusts, custom domains and signing certificates, and alert on every change.
- Automation credentials: admin API clients used by provisioning or reporting jobs get their own narrowly scoped credentials and a named owner. See the Identity provider (IdP) and SSO platform integration security guide.
Phase 2: authentication policy and user enrolment
CISA's guidance on implementing phishing-resistant MFA describes FIDO/WebAuthn as the only widely available phishing-resistant form, with PKI-based smart cards as the other, and advises starting with high-value users such as administrators and help desk staff. Build the policy set in report-only or audit mode first, then enforce by ring.
- Enrolment that cannot be hijacked: the first authenticator registration is the weakest moment. Require an existing strong credential, an in-person or verified session, or a temporary access code issued after identity verification, and notify the user on every new registration.
- Passwords where they remain: SP 800-63B-4 sets a minimum of 15 characters for single-factor passwords and 8 when used within MFA, at least 64 characters permitted, and a blocklist of compromised values. Failed attempts on one authenticator are limited to 100 before it is disabled.
- Push prompt abuse: CISA lists MFA fatigue (T1621 Multi-Factor Authentication Request Generation) among Scattered Spider techniques. Where push remains during transition, use number matching and rate limits, and move privileged users off it first.
- Session lifetimes: SP 800-63B-4 sets AAL2 reauthentication at no more than 24 hours overall with an inactivity timeout of no more than 1 hour recommended, and AAL3 at no more than 12 hours with no more than 15 minutes of inactivity recommended. See the Token Lifetime Policy Design Guide.
- Recovery is part of the rollout: agree the help desk verification procedure before the first user wave. Lost authenticators will spike in the first weeks. See the Account Recovery and Help Desk Security Guide.
The MGM Resorts Breach 2023 shows why: attackers reportedly called the help desk posing as an employee and later claimed administrator access to the identity tenant. A strong authentication policy with a weak reset procedure is a weak authentication policy.
Phase 3: application onboarding in waves
Inventory applications first (the application register or CMDB, plus discovery from network and expense data) and score each on data sensitivity, user count, exposure and protocol support. Then onboard in waves.
| Wave | Applications | Purpose | Exit criteria |
|---|---|---|---|
| Pilot | Two or three low-risk applications, one OIDC and one SAML | Prove the integration pattern, logging and support process | Patterns documented; no open sign-in defects |
| Wave 1 | Privileged and admin consoles, remote access, email | Protect what attackers want first | Phishing-resistant policy enforced; local admin logins disabled except break-glass |
| Wave 2 | Internet-facing SaaS with sensitive data | Remove standalone passwords where exposure is highest | Local password sign-in disabled for ordinary users |
| Wave 3 | Remaining SaaS and internal web applications | Coverage | Each application has an owner and a provisioning method |
| Wave 4 | Legacy applications without modern protocol support | Front with a gateway or schedule replacement | Exception register with review dates |
Integration rules for every wave:
- OIDC: authorisation code flow with PKCE, exact redirect URI registration and no implicit flow. RFC 9700 (BCP 240, January 2025) requires exact string matching of redirect URIs at the authorisation server and states the resource owner password credentials grant must not be used. See the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide.
- SAML: the OWASP SAML Security Cheat Sheet calls for validating signatures with a known key rather than one carried in the message, rejecting SHA-1, checking Audience, Destination, Recipient and InResponseTo, validating NotBefore and NotOnOrAfter with short assertion lifetimes, and detecting replay. Ask application owners to confirm their service provider library does this.
- IdP-initiated sign-in: OWASP notes it lacks login CSRF protection, and SP 800-63C-4 requires FAL2 transactions to begin at the RP. Prefer SP-initiated sign-in. See IdP-Initiated vs SP-Initiated SSO.
- No wildcards: SP 800-63C-4 forbids wildcards in domain or URI identifiers used for federation keys and endpoints.
- Provisioning and deprovisioning: SSO alone does not remove accounts. Connect SCIM or another provisioning method so leavers lose access in the application, not just at the IdP.
- Ownership: each integration records a business owner, a technical owner and the signing certificate expiry date.
Phase 4: retire legacy paths and the previous IdP
Coverage is only real once the alternatives stop working. Plan these as dated milestones, not clean-up.
- Local application passwords: disable local sign-in for ordinary users after each application is verified on SSO; keep one monitored emergency account per critical application.
- Legacy protocols: block protocols that cannot carry MFA once clients are migrated. See the Legacy Authentication and ROPC Retirement Guide.
- Previous IdP or federation server: remove its trust from each application, then decommission it and revoke its signing certificates. A forgotten federation server with a valid token-signing key is the forged-assertion path tracked as T1606.002 SAML Tokens. See the Golden SAML and Federation Trust Abuse Defence Guide.
- Hybrid synchronisation: if on-premises directory synchronisation or pass-through authentication remains, treat those servers as tier 0; ATT&CK tracks their abuse as T1556.007 Hybrid Identity.
Phase 5: launch, testing and rollback
- Test before each wave: sign-in, step-up, logout and session timeout per application; negative tests for an expired assertion, a wrong audience and a replayed response; a disabled user losing access within the service level.
- Report-only first: run new access policies in report-only mode for at least one business cycle and review what would have been blocked.
- Ring deployment: IT staff, then a volunteer business group, then department by department, with help desk staffing increased for each ring.
- Rollback: keep the previous sign-in method for each application deployable until the wave has run through a month end or equivalent peak. Record who can authorise a rollback and how long it takes.
- Outage plan: if the IdP is unavailable, which applications fail closed, which have emergency access, and how break-glass accounts reach critical systems. Rehearse once before full launch.
- Incident readiness: agree the response for a tenant takeover before go-live. See the Identity Provider Tenant Compromise Playbook.
Decision guidance
| Decision | Option A | Option B | Choose A when |
|---|---|---|---|
| Hosting | Hosted (SaaS) IdP | Self-managed IdP | You want managed availability and patching; choose B only with strong data residency or offline needs and the staff to run it |
| Cut-over style | Phased by application wave | Big-bang for all users | Almost always; B suits only small estates with few applications |
| Authenticator | Passkeys or security keys | Certificate-based smart cards | No existing PKI; choose B where a mature PKI and card estate already exist |
| Partner access | Federate to the partner's IdP | Guest accounts in your tenant | The partner manages identities well and signs a trust agreement; B gives you direct control of authenticators |
Small versus large organisations: a small organisation can often use the platform's secure defaults, onboard all applications in two waves and rely on hosted availability. A large organisation needs an identity product owner, an application onboarding team with a standard intake form, per-region rollout and a formal exception register. In both, admin protection and break-glass come first.
Detection and measurement
From the pilot onward, alert on: new identity providers or federation trusts, changes to signing certificates or custom domains, admin role assignments, authenticator registrations and resets for privileged users, bursts of MFA prompts for one user, sign-ins over legacy protocols, and break-glass use. CISA lists phishing-resistant MFA as the main mitigation against push bombing and SIM swapping, so track its adoption closely.
| Metric | What it shows |
|---|---|
| Applications on SSO / applications in register, by wave | Rollout progress against plan |
| Privileged users with phishing-resistant authentication only | Whether the highest-risk population is protected |
| SSO-integrated applications with local passwords still enabled | Whether old doors are actually closed |
| Help desk recoveries per 1,000 users per week during rollout | Enrolment friction and recovery exposure |
| Leavers disabled in downstream applications within the service level | Whether provisioning works, not only SSO |
| Policy exceptions open past their review date | Whether transitional exceptions are closing |
Once live, move to the quarterly Identity provider (IdP) and SSO platform health check.
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Centralised identity and SSO | IA-2 Identification and Authentication (Organizational Users) | PR.AA-01, PR.AA-03 | 6.7 |
| Phishing-resistant MFA | IA-2(1), IA-2(2), IA-5(2) | PR.AA-03 | 6.5 |
| Admin roles and least privilege | AC-6(5) Privileged Accounts, AC-5 Separation of Duties | PR.AA-05 | 5.4 |
| Partner and external users | IA-8 Identification and Authentication (Non-organizational Users) | PR.AA-03 | 6.7 |
| Account lifecycle | AC-2 Account Management | PR.AA-01 | 5.3, 6.2 |
| Configuration control of the tenant | CM-3, CM-6 | PR.PS-01 | 4.1 |
| Monitoring sign-in and admin activity | AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-03 | 8.2 |
Relevant ATT&CK techniques for detection design: T1078.004 Cloud Accounts, T1484.002 Trust Modification, T1606.002 SAML Tokens, T1556.007 Hybrid Identity and T1621 Multi-Factor Authentication Request Generation.
Common failure patterns
- Admins created before authenticators: admin accounts protected by SMS or push "for now", which becomes permanent.
- SSO without deprovisioning: users disabled at the IdP keep local accounts and API tokens in applications that were never connected to provisioning.
- Exceptions that never close: pilot exclusion groups and legacy protocol allowances with no expiry date. See How to Find Accounts Excluded From MFA and Conditional Access.
- Old IdP left running: the previous federation server stays trusted by a handful of applications, with a valid signing key and no monitoring.
- Help desk not ready: enrolment volumes overwhelm support, verification shortcuts appear and the reset path becomes the attack path.
- Broad trust permissions: too many people can add identity providers or domains, so a single compromised admin can create persistent federated access.
Practitioner checklist
- Record assurance targets (AAL, FAL) per population and application before configuration.
- Separate production and non-production tenants with no shared admins or signing keys.
- Create dedicated admin accounts with AAL3 authenticators, split roles and just-in-time elevation.
- Set up two tested break-glass accounts and stream audit logs to the SIEM before the pilot.
- Restrict and alert on new identity providers, federation trusts, domains and signing certificates.
- Onboard applications in risk-ordered waves with OIDC code flow and PKCE or fully validated SAML.
- Connect provisioning so leavers lose access in each application, not only at the IdP.
- Disable local passwords, legacy protocols and the previous IdP as dated milestones.
- Run policies in report-only mode, deploy by ring and keep a tested rollback for each wave.
- Hand over to the quarterly health check with baseline metrics recorded at go-live.
Standards and references
- NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
- NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- CISA: Implementing Phishing-Resistant MFA
- CISA: Scattered Spider Advisory AA23-320A
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- OWASP: SAML Security Cheat Sheet
- MITRE ATT&CK: Trust Modification
Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide, IAM and IdP Buyer's Guide, Identity provider (IdP) and SSO platform health check, Federation and Trust Relationships Guide, Passkey Rollout Guide.