A change in authentication methods that occurs after a legitimate sign-in but before the account is reviewed. In practice, it means the identity still looks valid while its trust anchor has quietly changed, which is especially dangerous for privileged users and cloud administrators.
Expanded Definition
Authenticator-registration drift describes a post-sign-in change to the registered authenticator set, such as adding a new device, token, passkey, or recovery path after the account has already been accepted as legitimate. In NHI operations, the risk is not the login itself but the quiet replacement or expansion of the trust anchor that later governs access.
Definitions vary across vendors and control stacks because the drift may be recorded in an identity provider, an application session, a PAM workflow, or a delegated federation layer. For that reason, NHI Management Group treats the term as a lifecycle integrity problem rather than a single alert type. It is closely related to authenticator binding, step-up verification, and recovery governance, but it is not the same as password reset. The key issue is that the account still appears valid while the security material behind it has changed, which can defeat review-based detection.
For baseline identity assurance concepts, NIST SP 800-63 Digital Identity Guidelines remains the most relevant external reference. The most common misapplication is treating any successful sign-in as proof that the authenticator state has not changed, which occurs when teams review access logs without validating enrollment events.
Examples and Use Cases
Implementing authenticator-change monitoring rigorously often introduces extra review overhead, requiring organisations to weigh faster recovery and user convenience against stronger assurance that a valid session has not been silently re-anchored.
- A cloud administrator signs in with a hardware key, then registers a new passkey from an unmanaged device before the access review cycle catches it.
- A service account owner uses a recovery process to swap the primary authenticator after an incident, but no control validates who approved the change.
- An attacker who has a live session adds a new MFA method and keeps persistence even after the original password is rotated, a pattern that mirrors the Salesloft OAuth token breach where trust changed without immediate detection.
- A federated admin account in a SaaS environment receives a new recovery email, and the identity provider continues to treat the account as healthy until the next governance check.
- An MFA reset performed by support adds a fresh authenticator without forcing privilege revalidation, leaving the account exposed until manual inspection.
In practice, drift is easiest to miss when organisations rely on session validity alone and do not correlate enrollment, recovery, and privilege events with a source of truth such as NIST SP 800-63 Digital Identity Guidelines or equivalent internal assurance policy.
Why It Matters in NHI Security
Authenticator-registration drift is a governance failure because it lets the trust boundary move without an explicit ownership decision. That is especially dangerous for NHIs, where service accounts, privileged bots, and cloud operators often outlive the people who created them. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, and drift turns that excess into an active persistence path rather than a static configuration weakness. When authenticator state changes outside formal review, offboarding, rotation, and access certification can all be rendered incomplete.
This is one reason weak visibility remains a structural issue: only 5.7% of organisations have full visibility into their service accounts, making post-enrollment changes hard to detect in time. Drift should therefore be monitored alongside secret sprawl, recovery events, and token issuance, not treated as a narrow MFA concern. The related control logic also aligns with identity hardening guidance in Ultimate Guide to NHIs.
Organisations typically encounter the consequence only after a privileged account is abused through a newly registered authenticator, at which point the drift becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Authenticator drift often follows weak secret and authenticator lifecycle controls. |
| NIST SP 800-63 | AAL2 | Defines assurance expectations for authenticators and reauthentication after binding changes. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication events must be governed across the account lifecycle. |
Correlate enrollment, recovery, and access events to detect unauthorized trust-anchor changes.
