If the organisation needs policy-driven enrollment, recovery, risk-based step-up, and multi-channel support, a separate orchestration layer is usually the better control point. The IDP can still issue sessions, but orchestration is where contextual decisions and lifecycle events stay coherent across the journey.
Why the control point matters more than the protocol path
The choice is less about where the passkey assertion is technically consumed and more about where policy decisions stay coherent. If enrollment, recovery, device change, step-up, and support flows are all handled in one place, the organisation can apply consistent rules across the whole lifecycle instead of fragmenting them between sign-in and recovery paths. That is why many teams treat orchestration as the operational control plane for passkeys.
When the IDP is the only control point, it often handles the authentication moment well but leaves recovery and exception handling scattered across support tooling, help-desk workflows, and downstream apps. A separate orchestration layer can keep those decisions tied to the same policy logic, which matters when a passkey is lost, a device is replaced, or a user needs to move between assurance levels without falling back to weaker methods.
That also makes the architecture easier to reason about during rollout. Passkeys are usually not a single event, they are a journey: enrollment, use, recovery, and re-binding. A central orchestration layer can keep that journey aligned with organisational policy even when the underlying IDP, authenticators, or support channels differ by population or platform.
Where IDPs are enough, and where orchestration adds real value
If the requirement is only basic passkey sign-in for a homogeneous user group, an IDP can be sufficient. The argument for a separate orchestration layer gets stronger when the organisation needs policy-driven enrollment paths, multiple recovery options, risk-based step-up, or different treatment for employees, contractors, and high-risk accounts. In those cases, orchestration is not just an integration convenience, it is the place where control decisions remain understandable.
Orchestration also helps when the business wants to avoid creating a hidden dependency on the help desk. Recovery is often the weak point in passwordless programmes, and support staff may be pressured to bypass policy when a user is locked out. A dedicated layer can encode the approved recovery state machine, so the organisation is not relying on individual operator judgement to keep authentication assurance intact.
A practical way to think about it is this: the IDP should issue the session, but the orchestration layer should govern how the user gets to that point and what happens when the happy path fails. Passwordless and Passkeys Guide explains the rollout and recovery issues that make that separation useful, while NIST SP 800-63 Digital Identity Guidelines provides the assurance and authenticating-factors context behind those choices.
Designing for recovery, step-up, and channel consistency
The main architectural test is whether the organisation can make one policy decision across web, mobile, help-desk, and fallback channels. If the answer is no, then passkey support will drift into exceptions that are hard to audit and harder to govern. Orchestration becomes valuable when it can evaluate context, then route the user into the right enrollment or recovery path without weakening assurance just to preserve convenience.
That same model also helps when passkeys coexist with federation, SSO, and legacy account recovery. The organisation may still use the IDP for primary authentication and session issuance, but it should not force every edge case through the same sign-in screen. A separate orchestration layer can decide when to allow passkey enrollment, when to require stronger verification, and when to escalate to human review rather than quietly reintroducing lower-assurance recovery.
For larger environments, this is also a consistency problem. Different products, different support teams, and different identity providers can produce inconsistent user journeys unless one policy layer owns the workflow. Identity Provider and SSO Security Guide is useful for understanding what the IDP should still own, while Workforce Identity Security Guide shows how passkeys sit inside broader workforce authentication and recovery design.
Risk and Threat Considerations
Passkey programmes usually fail at the seams, not at the cryptography. The biggest exposure is recovery abuse, where an attacker targets help-desk processes, device reset flows, or weaker fallback methods to bypass the stronger authenticator. Fragmented ownership makes that easier because policy, logging, and exception handling are spread across multiple systems and teams.
Failure mechanism: When sign-in, recovery, and step-up are governed by different tools, attackers can hunt for the weakest path, often through social engineering or support escalation rather than direct passkey compromise.
Impact: The organisation can end up with strong passkeys on paper but weak account assurance in practice, especially for privileged users or high-value accounts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance and authenticating factors for passkeys and recovery paths. |
| Recommendation — Apply assurance levels to enrollment, recovery, and step-up decisions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey lifecycle depends on secure authenticator enrollment, rotation, and recovery governance. |
| IA-2 — Identification and Authentication (Organizational Users) | The IDP still authenticates users even when orchestration owns the journey. | |
| Recommendation — Manage passkey lifecycle controls centrally and remove weak fallback paths. Ensure organizational-user authentication remains strong at the session boundary. | ||
| OWASP ASVS | V6 — Authentication | Passkeys are an authentication control and must satisfy sign-in and recovery requirements. |
| V10 — OAuth and OIDC | If the IDP issues sessions, token and federation handling stays part of the design. | |
| Recommendation — Verify passkey sign-in and recovery meet authentication requirements. Validate federated session issuance and token handling alongside passkey flows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Passkey enrollment, recovery, and fallback methods are account lifecycle controls. |
| Recommendation — Standardise account lifecycle and recovery paths for passkey users. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access to Assets | Passkey control affects how access is granted, recovered, and stepped up. |
| Recommendation — Centralise access decisions that govern passkey-mediated authentication. | ||
Practitioner Guidance
What to prioritise: Decide first whether recovery and step-up are business-critical control functions or just product features. If they materially affect assurance, place them under an orchestration layer rather than scattering them across the IDP and downstream apps.
What to verify: Check that the same policy engine can govern enrollment, lost-device recovery, support-assisted reset, and risk-based step-up without forcing operators to make ad hoc exceptions. If it cannot, the architecture is not yet coherent enough for broad rollout.
Common mistake: Teams often treat passkey deployment as a sign-in project and underinvest in the operational journey. That creates a polished login experience but leaves recovery as the place where assurance breaks down.
Practitioner takeaway: Use the IDP for authentication session issuance, but centralise the decisions that affect lifecycle, recovery, and exception handling wherever consistency and auditability matter most.
Related resources from NHI Mgmt Group
- Should organisations replace point DLP tools with an orchestration layer?
- Should organisations add a separate authorization layer alongside Authelia or Authentik?
- Should organisations use one scanner or an orchestration layer for AI code security?
- Should organisations add a separate governance layer on top of an API gateway for AI?