Who should control passkey policy in a federated login model?

The upstream identity provider should control passkey policy when it is the party issuing the assurance used by relying services. Downstream applications can consume that assurance, but they should not pretend they own the ceremony if they do not. Accountability sits where the authenticator is governed.

Why This Matters for Security Teams

In a federated login model, passkey policy is not just a user experience setting. It determines who can issue assurance, enforce authenticator requirements, and revoke trust when an identity event turns bad. If the upstream identity provider sets policy, downstream applications can rely on a consistent control point instead of fragmenting rules across every service. That matters because passkeys are only as trustworthy as the ceremony that governs enrollment, recovery, and authentication assurance.

Security teams often get this wrong by assuming each relying application should tune its own passkey rules. That creates policy drift, inconsistent assurance, and gaps in incident response. Current guidance across the NIST Cybersecurity Framework 2.0 and NHIMG research points toward central governance where the authenticator is managed. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that identity controls fail quickly when ownership is diffused rather than explicit.

For federated login, the real question is not who can display a passkey prompt, but who is accountable for the assurance behind it. In practice, many security teams encounter policy disputes only after users are already authenticating through inconsistent upstream and downstream rules.

How It Works in Practice

The upstream identity provider should own passkey policy when it is the source of authentication assurance. That means it governs enrollment requirements, allowed authenticators, phishing-resistant settings, recovery paths, and step-up logic. Downstream applications then consume the assertion or token produced by that upstream ceremony and make authorization decisions based on that assurance, not by reinventing the passkey rules locally.

Practically, this works best when policy is expressed once and enforced at the identity layer. The relying party should define the assurance level it requires, while the identity provider enforces how that assurance is achieved. That separation keeps the control plane clean: the IdP owns ceremony, the application owns access decisions. NHIMG’s Lifecycle Processes for Managing NHIs is relevant here because the same governance principle applies to non-human and human identities alike: lifecycle control must sit with the system that can actually issue and revoke trust.

• Set passkey enrollment standards upstream, including phishing resistance and recovery assurance.
• Require relying services to consume upstream claims, not define conflicting local passkey rules.
• Centralise revocation, reset, and reauthentication policy where the authenticator is governed.
• Use federation metadata and assurance mappings so applications know what the upstream event means.

Where identity governance is mature, this model reduces duplication and makes audits simpler. Where it is not, the same user may face different ceremonies in different apps, and administrators cannot tell which policy actually governed the login. That approach breaks down in multi-IdP estates, where each business unit runs a different federation stack because assurance levels no longer mean the same thing across the environment.

Common Variations and Edge Cases

Tighter central passkey control often increases coordination overhead, requiring organisations to balance standardisation against application-specific exception handling. That tradeoff is real in mergers, partner federations, and regulated environments where some services cannot immediately adopt the same upstream identity provider. Current guidance suggests the default should still be central ownership of passkey policy, but there is no universal standard for every federation topology.

One common edge case is delegated administration. A business unit may be allowed to manage enrollment campaigns or recovery workflows, but that does not mean it should redefine assurance policy. Another is step-up authentication: an application can request stronger assurance for a sensitive action, yet the upstream identity provider should still determine how that assurance is delivered. NHIMG’s Regulatory and Audit Perspectives and Standards sections are useful reminders that auditability depends on clear ownership, not just technical integration.

For organisations with multiple identity providers, the safest pattern is to designate a primary issuer of assurance and document how each downstream service interprets its claims. That prevents policy collisions, but it still requires periodic review. In practice, federated passkey governance breaks down when downstream teams are allowed to treat local convenience settings as if they were authoritative security policy.

Related resources from NHI Mgmt Group

• How does the consumer-secret-entitlement model help with governance at scale?
• Who should own policy decisions in a policy-based access control model?
• Who should own MFA policy when security and user experience pull in different directions?
• Who should own phone-based identity policy in a financial institution?