Passkeys in Firebase and GCP change account linking assumptions

At a glance

What this is: This is a how-to guide for adding passkeys to Firebase and GCP Identity with OpenID Connect, and its key finding is that first-login verification and account linking are the real control points.

Why it matters: It matters because IAM teams need to treat federated passkeys as an identity lifecycle problem, not just an authentication UX change, especially where duplicate accounts and credential binding risk can undermine governance.

👉 Read Descope's tutorial on adding passkeys to Firebase and GCP Identity

Context

Passkeys only improve identity assurance if the first enrollment and account-linking steps are tightly governed. In Firebase and GCP Identity, the issue is not whether OIDC works, but whether the user who links a passkey is actually the rightful account holder and whether duplicate identities are prevented.

This makes the article relevant to human IAM, not NHI governance. The same pattern applies across identity programmes: strong authentication can still create governance gaps if linking, recovery, and lifecycle rules allow one identity proof to overwrite or multiply another.

The primary challenge is account binding across authentication methods. Without explicit verification and linking controls, organisations can end up with duplicate user records, broken sign-in paths, or an attacker adding a passkey to the wrong account.

Key questions

Q: How should security teams prevent passkey enrollment abuse in federated login flows?

A: Security teams should require proof of account ownership before allowing a new passkey to be attached, and they should log enrollment as an identity lifecycle event. The main risk is not passkeys themselves, but unauthorized binding to an existing account through a weak first-login path or poorly controlled recovery flow.

Q: Why do passkey and password coexistence models create account governance risk?

A: They create risk because the same person can arrive through multiple authentication paths, which can produce duplicate records or ambiguous ownership if linking is not deterministic. IAM teams need one authoritative merge rule, otherwise access reviews, revocation, and audit trails become inconsistent across sign-in methods.

Q: What breaks when same-email account linking is not tightly controlled?

A: You get split identities, overwritten credentials, or a merge that does not reflect the true account owner. That can disrupt access continuity and make later offboarding unreliable, because the organisation no longer knows which record is authoritative or which factor was actually enrolled by the user.

Q: Who is accountable for passkey binding and recovery decisions in a federated IAM flow?

A: The IAM owner is accountable for defining the rules, while application teams are accountable for implementing them consistently. Federated authentication does not transfer governance responsibility to the identity provider. It only changes where the control is enforced and where the audit evidence must be collected.

Technical breakdown

How passkeys fit into OIDC federation for Firebase

The article uses Descope as an OpenID Connect provider, with Firebase acting as the identity store and relying party for application sessions. In practical terms, the OIDC flow handles authentication upstream, then Firebase exchanges that result for tokens the application already understands. Passkeys add phishing-resistant sign-in, but they do not remove the need for a trusted federation boundary, because the downstream application still depends on correct provider configuration, issuer trust, and redirect handling.

Practical implication: validate issuer, redirect, and client secret settings as part of authentication governance, not just application setup.

Why first-login verification protects account binding

The blog stresses verifying a user by email or phone on first login before allowing passkey enrollment. That requirement is about identity binding, not convenience. If the first enrollment path is not tied to a verified identity, a malicious actor could attach a passkey to someone else’s account and convert a one-time compromise into persistent access. In identity terms, the risk is credential attachment without authoritative proof of account ownership.

Practical implication: require verified ownership before passkey enrollment and treat enrollment as a privileged identity event.

User linking in Firebase without creating duplicate identities

Firebase can link accounts that share the same email, but the implementation choice matters. Using FirebaseUI can handle much of the merge logic automatically, while a custom SDK flow requires explicit handling of the account-exists-with-different-credential state and a controlled linkWithCredential sequence. This is an identity governance problem disguised as a developer convenience problem, because the wrong merge path can replace credentials, split user history, or create ambiguous account provenance.

Practical implication: test account-linking logic under real collision scenarios before rollout and review how merged identities inherit prior access.

NHI Mgmt Group analysis

Passkey rollout is an account-binding governance problem, not just an MFA upgrade. The article shows that stronger authentication still depends on who is allowed to bind a new factor to an existing identity. In human IAM, the failure mode is not weak cryptography but weak enrollment governance. Teams should treat passkey enrollment as a controlled identity event, not a user preference setting.

First-login verification is the control that separates secure federation from credential hijack. The article’s warning is clear: if a user is not verified before passkey creation, an attacker may bind a durable authentication method to the wrong account. That is a lifecycle failure, because the identity proof happens at enrollment and shapes every later sign-in. Practitioners should re-evaluate onboarding, recovery, and factor-binding rules together.

Duplicate account handling exposes a hidden identity graph problem. When the same email can exist across password and OIDC paths, the real question is which record becomes authoritative after linking. That affects access continuity, auditability, and offboarding. For IAM teams, the lesson is that federation does not eliminate identity sprawl unless account resolution is deterministic and governed.

Federated authentication only works when ownership, linking, and recovery are aligned. The article demonstrates that passkeys can coexist with legacy password flows, but only if the organisation decides how identities are matched, merged, and recovered. That makes this a strong fit for lifecycle governance and access assurance across human identities, not a narrow login tutorial.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap is why OWASP NHI Top 10 needs to be read alongside identity lifecycle controls, not in isolation.

What this signals

Passkey adoption will keep exposing weak identity binding first. Organisations that modernise authentication without tightening account linking will create cleaner logins and messier governance. The practical test is whether your IAM programme can prove who enrolled which factor, when the account was merged, and what access state carried forward.

Identity lifecycle controls now matter at enrollment as much as at offboarding. That shift is visible across human IAM and NHI governance alike, because the first binding decision often determines the later blast radius. Teams should align federation design with lifecycle evidence, not just sign-in success.

If your programme already tracks lifecycle and access review discipline, the next step is to make passkey binding and account merge events auditable in the same way. OWASP NHI Top 10 is a useful reference point for thinking about how identity trust can be abused when binding rules are weak.

For practitioners

• Treat passkey enrollment as a privileged identity event Require verified email or phone ownership before any new passkey can be bound to an existing account, and log the enrollment as an auditable identity change.
• Test account-linking collisions before production rollout Simulate same-email sign-ins across password and OIDC paths, then validate the exact linkWithCredential behaviour and resulting user record state.
• Define one authoritative account resolution rule Decide whether FirebaseUI or a custom SDK flow owns identity merging, and make the merge rule deterministic for duplicate identities.
• Review recovery and offboarding after federation changes Confirm that merged identities still inherit the right revocation, password reset, and recovery behaviour after a passkey is added.

Key takeaways

• Passkeys improve authentication assurance, but they do not fix weak account-binding governance.
• The critical control is first-login verification and deterministic identity linking, not the passkey mechanism itself.
• IAM teams should treat federation, recovery, and lifecycle evidence as one control set, or duplicate identities and unauthorized factor binding will follow.

Key terms

• Passkey Enrolment Fraud: Passkey enrolment fraud happens when an attacker gains temporary access to an account and registers their own device or authenticator as trusted. After enrolment, the attacker can authenticate legitimately because the system believes the new binding is valid. The weakness is not the passkey itself, but the governance around who can bind it.
• Account linking: Account linking is the process of tying multiple login methods or sessions to one user profile so the same person does not become several separate records. In consumer IAM, it preserves identity continuity across email, social login, device handoff, and guest-to-registered transitions.
• Federated Identity: Federated identity lets one organisation trust an external identity provider so a user can access another service without creating a separate account. It simplifies access, but it also expands the trust relationship that must be monitored. Weak federation settings can turn a single compromise into cross-domain access.
• Identity Binding: The process of linking an external credential or login method to an internal account record. Strong binding prevents duplicate accounts, broken recovery paths, and unsafe merges when users authenticate through different identity sources or wallet-based credentials.

What's in the full article

Descope's full blog covers the implementation detail this post intentionally leaves for the source:

• Step-by-step Firebase console configuration for OIDC provider setup and redirect handling
• Sample React and FirebaseUI code for building the passkey login path
• Manual SDK account-linking logic using linkWithCredential for duplicate-email cases
• Practical flow design notes for first-login verification and passkey enrollment

👉 Descope's full post includes the OIDC setup, FirebaseUI configuration, and custom linking code examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.