Who should own the controls for federated passkey account merging?

IAM or identity engineering should own the policy, while application teams implement the integration details. The reason is simple: the merge logic affects identity assurance, entitlement continuity, and recovery, so it belongs in governed identity design rather than ad hoc application code.

Why This Matters for Security Teams

Federated passkey account merging is not just a login convenience feature. It changes which identity is authoritative, how assurance is preserved across providers, and what happens when the same person arrives through two different trust paths. That makes it a governance problem, not a UI decision. NIST’s NIST Cybersecurity Framework 2.0 is clear that identity governance belongs in managed, repeatable control processes rather than one-off application logic.

The operational risk is that merge rules can unintentionally join separate accounts, drop MFA state, or preserve the wrong entitlements after a federation event. NHIMG’s Ultimate Guide to NHIs — Standards shows how often identity control failures become security failures once they are embedded in routine operations. For account merging, the same pattern applies: policy choices made in code are hard to audit, hard to change, and easy to get wrong across providers.

In practice, many security teams encounter broken recovery paths and entitlement drift only after a user is locked out or an account is merged incorrectly, rather than through intentional governance testing.

How It Works in Practice

IAM or identity engineering should own the merge policy because they can define the assurance thresholds, precedence rules, and recovery conditions once, then apply them consistently across all federated applications. Application teams should still own the integration details, but only within a centrally governed policy model. That separation matters because account merging touches identity proofing, session continuity, and entitlement inheritance at the same time.

A practical control model usually includes:

• Defined match criteria for when two federated identities may be merged.
• Assurance requirements for each IdP, including stronger checks for high-risk changes.
• Approval or step-up verification for merge events that affect privileged access.
• Logging that records the original identities, merge decision, and resulting authority chain.
• Rollback or remediation procedures when a merge is later found to be incorrect.

For implementation guidance, the NIST Cybersecurity Framework 2.0 supports structured identity governance, while NHIMG’s Ultimate Guide to NHIs — Standards reinforces that identity decisions need lifecycle controls, visibility, and ownership. The best practice is evolving toward policy-as-code for these merges, but there is no universal standard for every federation pattern yet, so teams should document local rules carefully and review them with security architects.

These controls tend to break down when each application implements its own merge heuristic because identity evidence becomes inconsistent across providers and recovery decisions stop being auditable.

Common Variations and Edge Cases

Tighter merge control often increases support overhead, requiring organisations to balance user convenience against the risk of account collision or unintended entitlement carryover. That tradeoff is especially visible when a user has multiple IdPs, moves between tenants, or changes email aliases over time.

Some environments should avoid automatic merging entirely for high-risk roles, regulated workloads, or accounts that carry privileged access. In those cases, current guidance suggests using a manual review path with strong proof of continuity rather than silent reconciliation. Other edge cases include guest identities, disabled accounts that later return, and federated accounts from partners with weaker assurance levels.

Security teams should also decide who can override a failed merge, because that exception path is often where abuse begins. NHIMG’s Ultimate Guide to NHIs — Standards is useful here as a reminder that exceptions need lifecycle governance, not informal approval. Where the assurance level from one identity provider cannot be validated against the other, the safest choice is usually to preserve separate accounts until a trusted review is complete.

Related resources from NHI Mgmt Group

• Who should own lifecycle controls for agent identity and federation?
• What is the difference between human IAM controls and NHI governance?
• When should organizations review access controls?
• When does a service account become a compliance problem?