In July 2026, Okta Threat Intelligence reported an increase in attacks targeting multi-factor authentication (MFA) enrollment and password reset processes. Attackers used social engineering and compromised credentials to trick users into approving unauthorized changes. Some campaigns exploited passkey enrollment as a pretext.

In certain scenarios, attackers used stolen passwords to access accounts with insufficiently protected MFA enrollment processes. They then registered authenticators under their control. On subsequent logins, the attackers could satisfy MFA challenges using their newly enrolled factors, despite having no legitimate entitlement to the accounts.

These attacks expose a fundamental weakness in MFA security: strong authentication cannot compensate for weak authenticator enrollment.

Effective MFA enrollment must establish who is authorized to register an authenticator while providing legitimate users with a secure, practical setup process. Organizations must verify that the person requesting enrollment is authorized to control the account before binding a new authenticator.

The same principle applies to authenticator recovery and replacement. If attackers can bypass enrollment protections through a password reset or help desk interaction, the strength of the original authentication method becomes less relevant.

Verify identity before binding an authenticator

Authenticator binding associates an authenticator with a subscriber account. Under the National Institute of Standards and Technology (NIST) Digital Identity Guidelines, this process is part of authenticator lifecycle management.

The central security challenge is determining whether the person requesting enrollment is authorized to bind an authenticator to the account.

Demonstrating possession of a phone, security key, or other authenticator does not establish entitlement to an existing account. An attacker may control a legitimate device while attempting to associate it with someone else’s identity.

NIST distinguishes between identity proofing, which establishes confidence in a claimed identity, and authentication, which verifies control of authenticators associated with an established subscriber account.

For new employees, identity proofing may begin during hiring or onboarding. A remote process can validate acceptable identity evidence and verify that the applicant is associated with the claimed identity. Depending on the required assurance level, this may involve authenticating a government-issued identity document and comparing its portrait with a live facial image.

However, verifying a person’s identity is only part of securing MFA enrollment.

Organizations must also establish that the verified identity corresponds to the account receiving the authenticator.

Consider an attacker who submits their own valid identity document while attempting to register an authenticator against another employee’s account. The identity verification result may be accurate, but the enrollment request remains unauthorized.

A secure process must therefore establish both the applicant’s identity, when identity proofing is required, and their authorization to modify the specific account.

For existing accounts, organizations should require authentication appropriate to the risk of the binding operation. When that authentication is unavailable or cannot be trusted, a controlled recovery or identity re-establishment process may be necessary.

Match MFA enrollment security to the access at stake

Not all authenticator enrollment requests present the same level of risk.

An employee with limited application permissions presents a different exposure than a privileged administrator who can modify security policies, access sensitive systems, or manage other users’ accounts.

Organizations should apply enrollment and recovery controls proportionate to the potential consequences of unauthorized access.

For privileged and sensitive accounts, phishing-resistant authentication should be a priority.

FIDO2 security keys and appropriately configured passkeys can provide phishing-resistant authentication through cryptographic mechanisms that bind authentication to the legitimate relying party.

Passkeys can also support multi-factor authentication when the authenticator requires an additional factor, such as a local PIN or biometric user verification, to activate the private key.

However, not every passkey implementation provides the same assurance. Applications must evaluate the authenticator’s properties and enforce user verification where required by the authentication policy.

The Open Worldwide Application Security Project (OWASP) similarly emphasizes the importance of validating authentication properties rather than assuming that the presence of a passkey automatically satisfies every security requirement.

For higher-risk accounts, organizations should also consider stronger controls for authenticator registration, replacement, and recovery.

The objective is to prevent an attacker from exploiting a weaker enrollment process to gain control of an otherwise strongly protected account.

Remove friction that encourages security exceptions

Secure enrollment must also be practical for the people expected to complete it.

A technically sound MFA deployment can still introduce security weaknesses if legitimate users cannot enroll successfully or repeatedly require manual exceptions.

In a May 2025 rollout update, the Defense Counterintelligence and Security Agency (DCSA) described persistent login difficulties and lengthy help desk wait times following an MFA deployment. The agency also identified incompatible technology environments across participating organizations.

Its response included additional setup guidance and live assistance sessions.

The experience illustrates an important operational lesson: MFA enrollment must be tested under real-world working conditions before broad deployment.

Enterprise teams should pilot enrollment across different user populations, devices, and access environments.

Testing should include employees who use assistive technologies, personnel who cannot use personal phones at work, and remote contractors who may not have access to on-site technical support.

Participants should complete the entire process, including their first protected sign-in after authenticator registration.

This helps identify whether users can successfully activate and use the approved authentication methods without relying on undocumented workarounds.

Reducing unnecessary friction also limits the pressure to introduce exceptions that may weaken the organization’s security posture.

Make authenticator recovery as secure as enrollment

Authenticator recovery is a critical part of the authentication lifecycle because it can authorize the replacement of an existing factor.

Attackers increasingly target this process to bypass otherwise effective MFA protections.

In its advisory on payroll-related attacks, Okta described scenarios in which attackers impersonated employees, persuaded help desk personnel to reset passwords, and subsequently enrolled authenticators under their control.

These attacks demonstrate why help desk procedures must be treated as security controls rather than administrative conveniences.

Organizations should restrict who can authorize authenticator resets and replacements. Recovery procedures should require verification appropriate to the account’s risk and the assurance level being restored.

For privileged accounts, additional approvals and independently verified recovery methods may be appropriate.

NIST SP 800-63B-4 also recommends encouraging subscribers to maintain multiple authenticators to reduce the need for account recovery.

However, organizations should evaluate whether those authenticators share a common point of failure.

For example, two authentication methods available exclusively through the same lost or compromised phone may not provide meaningful recovery resilience.

Where appropriate, organizations should encourage independent backup methods, such as a separate hardware security key or another approved authenticator.

The goal is to provide legitimate users with a reliable recovery path without creating an easier route for attackers to take control of their accounts.

Monitor authenticator changes and detect identity threats

Authenticator enrollment should not be treated as a one-time security event.

Even after registration is complete, organizations need visibility into authenticator additions, replacements, removals, and subsequent account activity.

NIST SP 800-63B-4 establishes requirements for authenticator lifecycle management, including records of significant authenticator events and notifications associated with certain account changes.

These controls help users and security teams identify changes that may not have been authorized.

However, notification alone is insufficient.

Users need a clear way to report suspicious authenticator registrations, while security teams need the ability to investigate and respond.

A newly registered authenticator may appear legitimate when evaluated in isolation. The surrounding sequence of events can reveal a different picture.

For example, an account may experience a password reset, followed by the enrollment of a new authenticator and an unusual login from an unfamiliar device or location.

Each event may appear successful independently. Together, they may indicate an account takeover attempt.

This is where continuous identity threat detection becomes important.

ID Dataweb recommends connecting identity-related signals across the account lifecycle rather than evaluating enrollment, authentication, and subsequent activity as isolated transactions.

Correlating changes in authenticators with session risk, device intelligence, and other identity signals can help organizations identify suspicious patterns that individual controls may overlook.

When risk indicators suggest unauthorized enrollment, organizations should have a defined response process. Depending on the available integrations and security policies, this may include suspending a suspicious authenticator, revoking affected sessions, requiring additional verification, or initiating an investigation.

The objective is to detect and mitigate identity threats even when an attacker has successfully completed an individual authentication step.

Measure enrollment success and ongoing protection

Enrollment completion rates provide useful operational information, but they do not tell the whole story.

An MFA program should measure whether legitimate users can successfully authenticate, whether recovery processes remain secure, and whether suspicious authenticator changes are detected and addressed.

Enterprise teams should monitor several complementary indicators:

  • Successful authentication: Can users complete a protected sign-in after registering their authenticators?
  • Enrollment friction: Where do legitimate users abandon the process or require additional assistance?
  • Security exceptions: Which user populations depend on overrides, alternative methods, or weaker authentication controls?
  • Unauthorized changes: How many authenticator registrations or replacements are disputed or associated with confirmed account compromise?
  • Recovery effectiveness: Can legitimate users regain access securely without excessive delays or repeated help desk intervention?
  • Threat detection and response: How quickly can security teams identify, investigate, and contain suspicious authenticator changes?

These measurements help organizations evaluate both the usability and security of their authentication lifecycle.

A successful MFA program should make it straightforward for legitimate users to establish and maintain secure access while making unauthorized authenticator enrollment significantly more difficult.

Strong MFA starts before the first authentication

MFA security depends on more than the strength of the authentication method.

Organizations must establish who is authorized to enroll an authenticator, protect the processes used to replace or recover factors, and maintain visibility into identity threats after enrollment.

This requires a coordinated approach that connects identity proofing, authenticator lifecycle management, risk-based authentication, and ongoing identity threat detection.

Enterprise teams should regularly test the complete journey, from initial authenticator registration through protected sign-in and lost-device recovery.

They should also evaluate whether enrollment policies accommodate different user populations without introducing unnecessary exceptions.

By strengthening authenticator enrollment and recovery while monitoring identity risk throughout the account lifecycle, organizations can reduce the likelihood that attackers turn legitimate MFA mechanisms into tools for account takeover.