The Password Changed, but the Attacker Stayed: Testing Identity Linking Across Every Sign-In Path

The victim resets the password, signs out every visible device, and regains access. Ten minutes later, the attacker selects "Continue with SSO" and receives a new session through an external identity linked during the compromise. No password is reused and no exploit is repeated. The application is honoring a relationship it still considers legitimate.

Account recovery often fails at this point because the playbook sees credentials as a list rather than identity as a graph. Passwords, magic links, social identities, enterprise federation, passkeys, API tokens, recovery methods, device sessions, and support-assisted flows can all create a route to the same local account. Rotating one node leaves the other edges untouched.

Each linking edge is an authorization decision with a history: which principal requested it, which proof confirmed control, which local account received it, and which sessions it may create. Recovery has to enumerate and challenge those edges. A successful password-change screen provides no evidence about the rest of the graph.

Key Takeaways

• Password rotation does not remove linked identity providers, passkeys, active sessions, recovery methods, API credentials, or attacker-established alternate sign-in paths.
• Identity linking is a privileged account transition: the current user must deliberately authorize the exact external identity, and both sides of the link must be verified under the intended policy.
• Matching email strings is not sufficient proof that two identities belong to the same person, especially across providers, aliases, recycled addresses, and unverified claims.
• Pre-account hijacking can occur before the victim registers when an attacker plants a credential that survives the victim's later verification or onboarding flow.
• Every login and callback route must converge on the same MFA, account-state, linking, session, and audit policy; a secure primary route cannot compensate for a weaker alternate handler.
• Effective incident recovery inventories and revokes the entire identity graph, then validates every sign-in path with replayable negative tests.

An Account Is an Identity Graph

Traditional diagrams often show one user record with a password hash. That model is too small for modern authentication. A more realistic account may contain:

Local account
  -> password credential
  -> passkey A
  -> passkey B
  -> enterprise subject (issuer X, subject 123)
  -> social subject (issuer Y, subject 456)
  -> verified email identifiers
  -> recovery phone or email
  -> active browser and device sessions
  -> personal access and refresh tokens
  -> pending invitations and enrollment intents

Each arrow grants some capability. Some create sessions directly. Some allow new credentials to be created. Some recover control when normal authentication fails. Some are pending and become active only after another event. A security response that changes one password but does not evaluate the rest assumes the account still has a single trust root.

The correct operational question is not "Was the password reset?" It is:

After recovery, which principals, credentials, identifiers, sessions, and delegated applications can still obtain authority over this account?

That question should be answerable from structured records. If identity associations are scattered across provider tables, plugin settings, token stores, and opaque audit messages, neither the user nor the incident responder can determine whether control was actually restored.

A Linked Identity Is a Durable Authorization Grant

When a local account links to an external identity, the application makes a durable statement:

Assertions from issuer I about stable subject S may authenticate local account U.

The stable key is normally an issuer-subject pair, not an email address displayed by the provider. Email can be useful as a verified attribute or discovery hint, but it is not a universally stable principal identifier. Two providers can verify the same email under different processes. Addresses can be reassigned. Aliases can normalize differently. Enterprise domains can change ownership. A claim can be absent, stale, or explicitly unverified.

Because the link creates future authentication authority, it needs the same seriousness as adding an authenticator. A currently authenticated session should not be allowed to attach arbitrary identities silently. The user should reauthenticate at an appropriate strength, initiate a bounded linking transaction, authenticate to the external provider, see what will be linked, and receive an independent notification after completion.

Three Persistence Patterns Teams Commonly Miss

Identity-linking weaknesses are not one bug class. They appear at different points in the account lifecycle.

1. Post-Compromise Linking

An attacker temporarily controls a session or password and adds an external login they own. The victim notices suspicious activity and changes the password. If recovery does not remove or challenge recently added links, the attacker signs in through the linked provider and regains access.

The original compromise might have been short-lived. The identity link turns it into persistence. This resembles adding a new SSH key after compromising a server: rotating the original password does not remove the newly trusted key.

Tests should establish a disposable attacker identity, link it while using a synthetic victim session, rotate the password, revoke expected sessions, and then attempt each linked login path. The evidence is not merely that the link remains listed. The meaningful result is whether it can still create a privileged local session after the stated recovery procedure.

2. Pre-Account Credential Planting

The attacker acts before the victim creates an account. Suppose registration allows a password account to be created using an email address without first proving control of that address. Later, the real owner signs in through a magic link or email code. If the application treats successful email verification as ownership of the pre-existing account while preserving the attacker's password, both parties now have access.

This pattern is especially dangerous because the victim's onboarding looks successful. There may be no suspicious password change or alert. The vulnerability comes from an invalid state transition: an unverified credential survives the moment the account becomes verified and authoritative.

A sound design either requires verification before creating durable authentication authority, quarantines unverified credentials, or invalidates all pre-existing credentials when a stronger ownership event claims the account. The exact product flow can differ, but ambiguity must resolve in favor of the verified owner, not credential continuity.

3. Alternate Handler Policy Drift

Applications accumulate sign-in routes: the main login page, an OpenID callback, a legacy plugin, a mobile deep link, an enterprise SSO endpoint, a command-line device flow, and an administrator portal. One route may enforce MFA and account suspension while another directly creates a session after finding a linked identity.

The link itself may be legitimate. The bypass occurs when the consuming handler applies a weaker policy. A user can be required to pass TOTP or WebAuthn on the primary route but receive a full session through an alternate callback that never invokes the step-up gate.

Testing must therefore follow links in both directions: how they are created and how each linked identity is consumed. Securing only the "connect account" screen leaves half the trust boundary untested.

Define the Identity-Linking Invariants

A reliable implementation starts with explicit invariants rather than framework defaults. A useful baseline is:

Link external principal (issuer I, subject S) to local account U only when:
1. the current actor is strongly and recently authenticated as U;
2. the actor deliberately initiated this exact linking purpose;
3. the external provider authenticated stable subject S for issuer I;
4. the pair (I, S) is not linked to another local account;
5. account, tenant, provider, and risk policies allow the link;
6. the transaction is completed once, within its lifetime, in the initiating context;
7. the owner can observe and revoke the resulting link.

For account creation or recovery, a second invariant applies:

Verification of identifier E must not silently preserve authentication authority
that was created before control of E was proven, unless policy explicitly proves
that the same verified principal established both states.

These rules prevent teams from relying on vague conditions such as emails match or OAuth callback succeeded. A successful protocol exchange establishes facts about an external subject and transaction. The application still decides what those facts may do locally.

Link Transactions Need Their Own State

Do not infer linking intent merely because a signed-in browser returned from an identity provider. Create an explicit transaction with fields such as:

Consume the transaction atomically. Two callbacks should not produce two links, and one transaction should not be convertible from login to link by changing a query parameter. Server-side state or integrity-protected data must bind the purpose; client routing alone is not enough.

Email Matching Is an Identification Hint, Not Ownership Proof

Automatic account linking by email feels convenient. A user signs in with a new provider, the provider returns the same email, and the application merges the identity into the existing account. The convenience hides several assumptions:

• Did the provider actually verify the email?
• Is the provider trusted to verify that domain and account type?
• Is comparison case-sensitive or normalized consistently?
• Can aliases map to the same mailbox but represent distinct organizational identities?
• Can the address be recycled after employment or subscription ends?
• Does the local account still consider that email authoritative?
• Is the provider subject stable, or can its meaning change?
• Was the user intending to link, or only trying a sign-in button?

The safest general rule is not to link solely because strings match. If discovery finds an existing account, require the user to authenticate to that account through an already trusted method, then complete an explicit linking transaction. In enterprise environments, controlled domain federation can support more automated provisioning, but the trust must be documented and scoped to issuer, tenant, domain ownership, and lifecycle events.

Avoid Account Enumeration During Collision Handling

When an external identity or email collides with an existing account, the response should not reveal unnecessary account details. "That provider subject is already linked to Alice at Company Z" helps attackers map identities. Provide a generic recovery or sign-in path while recording a precise internal reason code.

Do not resolve the privacy problem by auto-merging. Ambiguity should block the link and direct the user through a controlled proof process.

Every Sign-In Path Must Reach the Same Security Decision

Authentication frameworks often expose separate handlers for password, magic link, federation, social identity, passkey, recovery, and API flows. The adapters can parse different protocols, but they should converge before a session receives final authority.

The shared service should receive normalized facts, not a request to "trust this provider." It can then decide whether the account is active, whether the identity association is valid, whether step-up is required, which tenant is selected, what session assurance to assign, and which security event to record.

Do Not Let the Callback Mint Authority Directly

A common design error is to create the local session inside each callback handler. Over time, the handlers diverge. One checks suspension, another checks MFA, and a third sets an administrator session based on a stale link.

Prefer a central session-issuance boundary:

externalCallback(request):
    assertion = providerAdapter.validate(request)
    transaction = linkOrLoginTransactions.consume(request.state)
    identity = identityLinks.resolve(assertion.issuer, assertion.subject)

    decision = accessPolicy.evaluate(
        purpose=transaction.purpose,
        account=identity.account,
        tenant=transaction.tenant,
        providerAssurance=assertion.assurance,
        localRisk=currentRiskSignals()
    )

    return sessions.issueOnlyIfAllowed(decision)

This does not eliminate protocol-specific validation. It prevents protocol adapters from becoming independent authorization systems.

Test the Full Account Lifecycle

Point-in-time tests miss identity persistence because the dangerous effect often appears after another event. Build sequences that cross lifecycle boundaries.

Before Registration

Attempt to create accounts and credentials using an email that has not been verified. Then let the synthetic victim prove control through each supported onboarding method. Check whether attacker-created passwords, sessions, provider links, API tokens, or recovery methods survive.

During Normal Account Use

From a recently authenticated session, try linking an external subject under correct and incorrect reauthentication states. Change the local email or provider email during the transaction. Reuse state, switch browsers, substitute provider, and attempt to link an identity already owned by another local account.

After Credential Change

Simulate the documented "change password" and "secure my account" procedures. Attempt login through every linked provider, passkey, magic-link route, recovery method, refresh token, and active device. The expected result depends on product policy, but it must match what the user and incident responder are told.

After Suspension, Tenant Removal, or Role Change

A valid link should not override a disabled local account or deleted tenant membership. Test whether an external callback can recreate a membership, select a stale privileged tenant, or receive a session whose roles were cached before removal.

During Unlinking and Account Deletion

Unlinking must revoke future use of the association and address existing sessions according to policy. Account deletion should not leave an external identity reserved indefinitely without a clear retention reason, nor should immediate reuse allow one person's old link to attach to another person's new account.

An Autonomous Validation Workflow

The number of identity combinations grows quickly. An autonomous pentest workflow can help when it is driven by explicit state and safe fixtures rather than indiscriminate login attempts.

1. Build the Identity Surface Map

Enumerate sign-in buttons, callback routes, mobile deep links, API schemas, provider configurations, account-link settings, recovery paths, session stores, and credential tables. Connect each route to the service that resolves identity links and issues sessions.

2. Create Synthetic Principals

Use dedicated local accounts and external provider identities controlled by the test environment. Include a victim, attacker, tenant administrator, ordinary member, suspended user, unverified pre-account, and identity already linked elsewhere. Use fake domains and non-production providers where possible.

3. Record Valid Baselines

Complete login and linking through each supported path. Record expected claims, transaction state, account associations, assurance, resulting roles, sessions, notifications, and audit events. Baselines prevent malformed protocol traffic from obscuring business-logic tests.

4. Mutate Relationships and Sequence

Change one meaningful fact at a time: external subject, issuer, email verification flag, current local session, target account, tenant, transaction purpose, state, timing, account status, or pre-existing credential. Then create multi-step sequences such as link, rotate password, revoke sessions, and re-login.

5. Verify Durable State and Authority

Inspect the identity graph before and after. Determine whether an association was created, whether old credentials remain, which sessions survive, and what permissions a new session receives. A callback 302 or a generic error page is not a sufficient oracle.

6. Turn Proof into Regression

Preserve a sanitized sequence with synthetic identities, expected policy decisions, and state assertions. Replay it when authentication adapters, account models, session code, provider libraries, recovery logic, or tenant policies change.

For teams using SecureHup, the practical benefit of this approach is not another list of theoretical authentication concerns. It is a shorter path from a suspected identity-graph weakness to evidence of whether access actually persists, plus a repeatable check that the remediation closes every affected route. That helps users prioritize real account-control risk, reduce manual triage, and give developers a concrete state transition to fix without turning the article or the assessment into a product demonstration.

Build a Persistence Test Matrix

The following matrix can seed automated and manual assessments:

The matrix should be tailored to documented behavior. Some products deliberately preserve selected sessions after a password change; others revoke everything. The security defect is not simply that a credential remains. It is a mismatch between the intended recovery guarantee, the user's reasonable understanding, and the actual authority graph.

Incident Recovery Must Revoke Trust, Not Just Secrets

When identity compromise is suspected, responders need a trust-recovery playbook. A complete sequence may include:

1. Establish a verified recovery channel and protect the responder session.
2. Snapshot identity links, authenticators, sessions, tokens, recovery methods, recent profile changes, tenant memberships, and delegated applications.
3. Disable or challenge suspicious and recently added associations.
4. Rotate the password and any applicable recovery secrets.
5. Revoke active sessions, refresh tokens, API tokens, device grants, and remembered-device state according to risk.
6. Review email, phone, passkey, MFA, external-provider, and notification-channel changes.
7. Re-establish approved authenticators through a controlled flow.
8. Verify tenant roles, application grants, forwarding rules, and recovery contacts.
9. Test every login path after recovery.
10. Notify the owner and retain an attributable incident record.

Blindly deleting every external link can lock out legitimate users and disrupt enterprise federation. The playbook should support review and selective re-verification. What cannot happen is treating password rotation as proof that all other authority disappeared.

Make Recovery Claims Precise

User-facing language matters. A button labeled "secure account" creates a stronger expectation than "change password." If the operation leaves active provider links or sessions, explain that and offer a broader recovery action. Incident responders also need to know whether session revocation is immediate, whether downstream tokens remain valid, and whether external identities can relink automatically.

Security tests should verify the promise the interface and runbook make. A technically documented exception hidden in implementation code is not an adequate recovery contract.

Engineering Controls That Reduce Linking Risk

Use Stable External Keys

Store and resolve external identities using an issuer and stable subject pair. Treat display names and emails as attributes. Validate issuer, audience, signature, nonce, transaction state, and other protocol requirements before identity resolution.

Require Explicit, Recent Authorization

Linking should be initiated from a protected account-security context and require recent authentication appropriate to account risk. High-impact tenant administrators may need stronger step-up than ordinary consumer accounts.

Make Collisions Fail Closed

Enforce uniqueness on the external principal association. If a subject is already linked elsewhere or the state is ambiguous, stop and require controlled recovery. Race-safe database constraints should back application checks.

Quarantine Unverified Authority

Do not let an unverified email create durable password, recovery, token, or provider authority that silently survives later ownership verification. Model pending accounts and pending credentials explicitly, with expiry and promotion rules.

Centralize Session Issuance

Every adapter should converge on shared account-state, tenant, assurance, MFA, risk, and audit decisions before receiving an authoritative session. Test that no callback constructs privileged sessions directly.

Expose and Notify Link Changes

Users and administrators need a complete list of linked methods with meaningful provider, creation time, last use, initiating context, and revocation controls. Send independent notifications when a link is added or removed. Avoid including sensitive tokens or excessive identity data.

Preserve Causal Audit Records

Record who initiated the link, which local account and tenant were affected, which issuer-subject pair was attached, which assurance and policy were used, and which session resulted. Protect audit data and avoid using mutable email as the sole identifier.

CI/CD Tests Should Follow the Identity Graph

Authentication regressions are often introduced by integration work that appears isolated: adding a provider, upgrading a callback library, changing email normalization, supporting a mobile route, or refactoring session issuance. Diff-aware test selection should connect those changes to identity-linking invariants.

At minimum, maintain:

• Unit tests for link policy, collision handling, account state, tenant membership, and assurance mapping.
• Transaction tests for state, nonce, purpose, expiry, single use, browser-session binding, and concurrent completion.
• Integration tests for every provider adapter and sign-in route converging on central session policy.
• Lifecycle tests spanning pre-registration, verification, password change, recovery, suspension, membership removal, unlinking, and deletion.
• End-to-end persistence tests that attempt actual session creation with synthetic linked identities after recovery.
• Audit and notification assertions that prove security changes are visible and attributable.

Useful metrics include the percentage of sign-in paths covered by shared session policy, number of identity associations without stable issuer-subject keys, time to revoke all authority during a recovery exercise, alternate-route MFA parity, pre-account state transitions tested, and confirmed persistence regressions. A count of successful password resets says little about identity recovery quality.

Identity-Linking Review Questions

Before shipping an authentication or account-linking change, ask:

• Are external identities keyed by stable issuer and subject rather than email alone?
• Does linking require an explicit transaction and recent authentication to the local account?
• Are login, link, recover, and register purposes cryptographically or server-side bound?
• Are state, nonce, issuer, audience, redirect, and code-exchange protections enforced by maintained adapters?
• Does a database constraint prevent one external principal from linking to multiple local accounts?
• What happens to credentials created before an email or account is verified?
• Can any callback create a session without central account-state, tenant, MFA, and risk checks?
• Does suspension or membership removal take effect across every provider route?
• Does password change or account recovery revoke exactly what user-facing documentation promises?
• Can the owner see, attribute, and revoke every linked identity and authenticator?
• Are link additions and removals independently notified?
• Do synthetic persistence sequences run after changes to auth, session, recovery, tenant, or provider code?

Frequently Asked Questions

Why can an attacker remain after the victim changes the password?

The attacker may have established another trusted path, such as a linked external identity, passkey, recovery method, refresh token, or active session. Password change affects only the password credential unless the recovery workflow explicitly reviews and revokes the wider authority graph.

Is it safe to link accounts automatically when verified emails match?

Not as a general rule. Verification quality, provider trust, address recycling, aliases, normalization, tenant policy, and user intent can differ. A safer default requires authentication to the existing local account and an explicit linking transaction, unless a tightly governed enterprise federation policy establishes equivalent trust.

What is pre-account hijacking?

It is a class of attack in which an adversary creates account state or a credential using a victim's identifier before the victim registers. If the later verification or onboarding process claims that state for the victim without removing the attacker's authority, both may retain access.

Should changing a password revoke all sessions and linked identities?

The correct behavior depends on product policy and risk. A routine password update may preserve selected sessions, while an account-compromise recovery should usually offer much broader revocation and link review. The crucial requirement is that behavior is explicit, visible, and consistently enforced across every sign-in path.

How do autonomous tests prove an identity-linking vulnerability?

They use controlled local and external identities, perform a permitted or attacker-like link sequence, trigger a lifecycle event such as password rotation or suspension, and then attempt to obtain a real synthetic session through each alternate path. Protected identity and session state provides the oracle; response codes alone do not.

Recovery Follows the Whole Identity Graph

Working backward from session-issuing endpoints reveals the passwords, external subjects, authenticators, tokens, recovery methods, tenant memberships, and pending transactions that can satisfy them. Edges created or used during the exposure window may need revocation or renewed proof, followed by a controlled attempt with the suspect identity material.

The resulting evidence should show both sides of recovery: the rightful owner can authenticate, while the displaced principal cannot return through an alternate callback, linked provider, stale device, or unfinished enrollment. We would keep those sequences with account-linking and recovery changes. One credential with a new value is progress; a graph with one intended owner is the stronger closure claim.

#IdentitySecurity #AccountTakeover #OAuthSecurity #FederatedIdentity #MFA #ApplicationSecurity #AutonomousPentesting