Without account linking, the same person can end up with separate user records for password and passkey sign-ins, or one provider may overwrite the other. That breaks auditability, offboarding, and access reviews because the identity record no longer represents a single authoritative account state.
When Firebase does not link password and passkey sign-ins, what breaks?
Firebase account linking is what lets multiple sign-in methods resolve to one authoritative user record. When it is missing, password and passkey logins can split into separate accounts, or the second provider can replace the first. The practical result is not just awkward UX, but broken identity continuity across audit, deprovisioning, and access review workflows.
Why separate credential paths create an identity integrity problem
Account linking is an identity reconciliation function. A person may authenticate with a password on one day and a passkey on another, but the system still needs to treat those events as the same account. Without that merge point, the platform loses a stable mapping between the human, the credential set, and the lifecycle state of the account.
That matters because access decisions, recovery paths, and account status all depend on one authoritative record. If Firebase maintains two records for the same user, one record can look active while the other is disabled, stale, or never reviewed. The security issue is not merely duplication, it is that the identity no longer tells the full truth about who the user is and how they sign in.
In practice, this also affects federated or mixed-mode sign-in. A user who starts with password login and later adopts passkeys should not become a new principal with a different history, different entitlements, or a different offboarding outcome. Account linking is what preserves continuity when authentication methods change.
What operational controls stop working when identity records split
Auditability is the first control to degrade, because login events, recovery actions, and privilege changes no longer roll up to a single account history. Offboarding is next: revoking one record does not guarantee the linked sign-in path is also removed, so access can survive in the shadow account. Reviews also become unreliable because recertification may validate the wrong record or miss one of the duplicate identities entirely.
For teams using Firebase, the Workforce Identity Security Guide is useful here because it frames passkeys, federation, account recovery, and lifecycle control as one joined-up identity problem rather than separate login features. The same principle is reinforced by Passwordless and Passkeys Guide, which treats passkeys as a sign-in method that still has to fit a controlled account and recovery model.
If linking is absent, you also lose clear evidence for support and security operations. Help desk resets, device changes, or re-enrollment events can become ambiguous because staff cannot confidently tell whether they are looking at an upgrade of the same identity or the creation of a new one. That ambiguity is where recovery mistakes and unauthorized persistence tend to hide.
How to think about the Firebase failure mode in practice
Firebase account linking should be treated as part of identity lifecycle design, not as a cosmetic developer option. The important question is whether each person has exactly one account state that carries all sign-in methods, recovery state, and lifecycle actions. If the answer is no, then the implementation is already violating the assumptions behind review, offboarding, and incident response.
The strongest internal analogue is the way Break-Glass and Emergency Access Account Guide treats emergency access as something that must be explicitly governed, monitored, and distinct from ordinary accounts. The same governance mindset applies here: alternate access paths are safe only when they are deliberately tied back to the same authoritative identity record.
For supporting evidence on why Firebase misconfiguration is operationally serious, Firebase misconfiguration exposure 2024 shows how configuration mistakes in Firebase environments can scale into large data exposure events. While account linking is a different control from database rules, both fail in the same way when the platform stops enforcing a clean boundary around identity and data.
Risk and Threat Considerations
When account linking is missing, the risk is identity fragmentation: a legitimate user can retain access through an alternate record even after the primary account is corrected, disabled, or reviewed. That creates a path for stale access, failed revocation, and misleading audit trails, especially in environments where passwords and passkeys coexist during migration.
Failure mechanism: The application treats two authentication methods as two separate identities, or lets one sign-in method overwrite the other, so lifecycle actions apply to only part of the user’s actual access state.
Impact: Offboarding and access review lose reliability, recovery can recreate the wrong account, and attackers or former users may preserve access through the unlinked path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Duplicate user records undermine who is authenticated and how login states are tied to one user. |
| IA-5 — Authenticator Management | Passkey and password paths must share governed credential lifecycle and recovery handling. | |
| AU-2 — Event Logging | Split accounts weaken the audit trail because actions no longer aggregate to one user history. | |
| Recommendation — Bind all sign-in methods to one authenticated user identity. Manage authenticators so changes do not create parallel accounts. Log authentication and account-linking events under one account history. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The issue is identity lifecycle continuity across multiple authentication methods. |
| A.5.17 — Authentication information | Passkeys and passwords are authentication information that must map to the correct account. | |
| Recommendation — Ensure one managed identity represents all sign-in methods. Control authentication methods so they remain bound to the right account. | ||
Practitioner Guidance
What to verify: Confirm that each user has one stable Firebase user record that survives a change in sign-in method, and test both directions, password to passkey and passkey to password. If either direction creates a new principal, account lifecycle controls are not trustworthy.
Common mistake: Treating passkeys as a replacement for account governance rather than a new authenticator bound to the same identity. The implementation can be technically successful at login and still fail operationally if the account model is duplicated.
Decision rule: If a sign-in method change can affect offboarding, audit history, or help desk recovery, linking is not optional, it is a core control requirement.
Practitioner takeaway: The real failure is not “password versus passkey”, it is losing one authoritative account state; if the identity record cannot represent every way the person signs in, the rest of the lifecycle controls will eventually drift.
Related resources from NHI Mgmt Group
- What breaks when account linking is not controlled across authenticators?
- What breaks when same-email account linking is not tightly controlled?
- What breaks when passkey providers are not configured consistently across Android devices?
- What breaks when account linking is not handled carefully in modern IAM environments?