A control that requires a user to prove identity through the original authentication method before a new SSO method is added. It reduces account linking abuse because an attacker who only controls an alternate IdP or email verification path should not be able to attach themselves to an existing account.
Expanded Definition
Re-verification on a new login method is a safeguard for authentication, session, and access control flows. It means a user must prove control of the original sign-in method before another SSO path, social login, or federated identity route can be attached to the account.
The control exists to preserve account binding. If a user can add a new login method with only a weak email check or a newly controlled identity provider, an attacker can exploit the account-linking process rather than the primary password or MFA flow. In practice, the original method is the anchor, and the new method is treated as a change to a trusted access path, not a routine preference toggle.
Industry usage is fairly consistent, but implementation details vary. Some products require a recent re-authentication, while others require the original IdP, passkey, or recovery factor. The common boundary is that the control protects account ownership transitions, not ordinary sign-in. That distinction matters because the risk is not just login failure, it is unauthorized expansion of account access through a new trust relationship.
Examples and Use Cases
- A user signs in with a corporate SSO account, then adds a personal Google login so they can access the same workspace later without repeated prompts.
- A support workflow asks a customer to confirm the original method before a new passkey or federated login is registered after a device replacement.
- An enterprise app allows both password and SSO, but requires the currently active method to approve the addition of another method to prevent silent account takeover.
- A recovery flow uses re-verification before linking a second IdP, which reduces the chance that an attacker can hijack account recovery and persist through a new access path.
The main trade-off is usability versus assurance. More re-verification steps slow down account setup and support cases, but they also make method-linking decisions more trustworthy, especially in environments that accept multiple identity providers or consumer-style login choices.
Security Implications
When re-verification is weak or skipped, the account-linking step becomes a high-value abuse path. Attackers often prefer this route because they may not need to defeat the original password or MFA factor directly; they only need one alternate path into the linking workflow.
That creates several concrete failure modes: unauthorized SSO attachment, takeover persistence after password reset, and confusion about which method actually governs the account. A compromised mailbox, an intercepted recovery flow, or a poorly protected alternate IdP can become enough to mint a lasting foothold. In shared or federated environments, that can also blur ownership boundaries and make incident response slower because the attacker’s access looks “legitimate” after the link is created.
Practitioners should treat method-linking events as security-sensitive account changes, not convenience events. They deserve logging, review, and clear user notification because the blast radius is the whole account, not just the added method.
Security, Operational and Governance Implications
This control sits at the intersection of account recovery, identity binding, and trust governance. It is especially important where a single account can accept multiple sign-in methods, because each added method increases the number of pathways that can be abused for persistence or unauthorized re-entry.
Operationally, the control also clarifies ownership. If the original method is no longer available, organisations need a deliberate recovery process rather than a silent fallback into any reachable email or federated login. Governance teams should define which changes require step-up verification, which events are auditable, and which changes trigger user notification or admin review.
For practitioners, the key question is whether the new login method changes the account’s trust boundary. If it does, the act of linking it should be handled like a privileged account change, with stronger verification and clear traceability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Identity and Authorization Abuse | Covers account-linking abuse through unauthorized access-path changes. |
| A6 — Tool and Access Misuse | Relevant where a new access route can be abused to gain lasting account control. | |
| Recommendation — Require step-up verification before adding any new login or delegation path. Treat newly added access paths as potential persistence mechanisms and monitor them closely. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Binding and Authentication | Addresses binding an account to trusted identities and preventing unauthorized linkage. |
| NHI-02 — Secret and Credential Lifecycle | Method-linking attacks often succeed through weak recovery or credential replacement flows. | |
| Recommendation — Verify the original authentication method before attaching a new identity or login method. Log and review login-method changes as sensitive credential lifecycle events. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
