Join our Newsletter — 33% off our NHI Course

What should identity teams document before adding a new authenticator?

They should document the trust source, the assurance level, the fallback path, and the lifecycle owner for each authenticator. Without that inventory, the enterprise can end up with multiple login routes that reach the same application but are governed very differently.

What belongs in the authenticator record before launch?

Identity teams should treat a new authenticator as a governed trust path, not just a login method. Before approval, the record should show what proves the authenticator is trusted, what level of assurance it provides, what happens if it fails or is unavailable, and who owns its lifecycle. That prevents silent differences between sign-in routes that look similar to users but carry different risk.

The trust source is the basis for deciding whether the authenticator can be accepted at all. In practice, that means recording where the trust comes from, how the factor is enrolled or verified, and what evidence supports that decision. For stronger sign-in methods, teams should align the documented trust source with the level of assurance expected from NIST SP 800-63 Digital Identity Guidelines.

The lifecycle owner is equally important because authenticators drift over time. A factor that starts out well controlled can become a weak path if no one owns support, recovery, reset, decommissioning, or exception handling. The clearest way to keep that visible is to anchor the authenticator to the broader identity program in the Workforce Identity Security Guide, where lifecycle and recovery are treated as part of the control, not afterthoughts.

Fallback path documentation matters because the exception route often becomes the real route. If the primary authenticator fails, users may be pushed into password reset, help desk verification, recovery codes, or another alternate method, and each of those can have a different security posture. That is why the fallback path should be described as part of the authenticator, not buried in separate operations notes. It also helps teams spot when a supposedly strong factor is being undercut by a weaker recovery mechanism, a theme reinforced in the Passwordless and Passkeys Guide.

Why the inventory has to distinguish similar login routes

Two authenticators can reach the same application while carrying very different trust properties. One may be phishing-resistant and strongly bound to the user, while another may rely on a shared secret, weaker recovery, or a less trusted enrollment channel. If teams do not inventory those differences, policy can drift from implementation and users can be placed onto an easier bypass path without anyone noticing.

That distinction is especially important when organisations allow multiple ways to satisfy step-up, recovery, or exception access. The control question is not only whether the user can sign in, but whether the organisation knows which route was used and what assurance it really delivered. In this area, the difference between strong and weak login paths is central to MFA Guide decisions about enrollment, bypass, and phishing-resistant options.

Inventory quality also affects auditability. If the business cannot tell whether an authenticator was approved because it met a specific trust source and assurance threshold, then later access reviews, incident reviews, and exception approvals become guesswork. Good documentation turns the authenticator set into something that can be reviewed, compared, and retired instead of merely remembered.

What should be true before an authenticator is added?

Before adding a new authenticator, the team should be able to answer four operational questions without debate: who owns it, what trust source makes it acceptable, what assurance level it is intended to satisfy, and what the user or service will do when it cannot be used. If any of those answers are vague, the safest move is to delay launch rather than let the new factor enter production as an exception.

What to verify: Verify that the fallback route is not weaker than the primary route without being deliberately approved and documented. Verify that recovery and reset paths are owned and monitored, because those paths often become the real attack surface when sign-in breaks. Verify that the record identifies the authenticator’s place in the lifecycle so removal, rotation, or replacement can be handled cleanly.

What good looks like: A mature inventory makes it easy to see which authenticators are high assurance, which are legacy, which depend on recovery, and which should be retired. The organisation can then enforce different rules for different methods instead of applying one generic login policy to everything.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-63 Digital Identity Guidelines Authenticator trust and assurance level are governed by identity assurance guidance.
Recommendation — Map each authenticator to its assurance target and align fallback paths to the same trust standard.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management The question is about documenting authenticators, fallback paths, and lifecycle ownership.
Recommendation — Track issuance, rotation, revocation, and recovery ownership for every authenticator.
ISO/IEC 27001:2022 A.5.16 — Identity management Authenticator inventory and ownership are part of controlled identity lifecycle management.
Recommendation — Record ownership and lifecycle status for each authenticator before approval.
OWASP ASVS V6 — Authentication Authenticator choice and recovery paths affect authentication assurance and verification.
Recommendation — Verify that each authentication method and recovery path meets the required assurance level.

Practitioner Guidance

What to prioritise: Treat new authenticator approval as a control-design decision, not a convenience decision. The first review should be whether the proposed method can be trusted at the required assurance level and whether its recovery path preserves that same standard.

Common mistake: Teams often document the method name but not the exception route. That leaves a gap where a strong primary authenticator is quietly paired with a weak reset flow, help desk override, or undisclosed alternate factor.

Decision rule: If the fallback path is less resistant to phishing, takeover, or social engineering than the primary authenticator, record it as a separate risk decision and require explicit ownership before rollout.

Practitioner takeaway: The real control is not “having another login option”, it is knowing exactly which trust path is being added, what assurance it provides, and who is accountable when that path changes or fails.