Who should own authentication risk when regulators ban OTP login?

Why authentication ownership becomes a board-and-control issue

When a regulator bans OTP login, authentication stops being a local IT setting and becomes a regulated control chain. Ownership has to reflect that the login method, recovery path, and monitoring all affect customer harm, fraud exposure, and supervisory scrutiny. In practice, that means the accountable owner must be able to direct policy, funding, incident response, and evidence collection together.

The strongest model is shared accountability with a clear single owner. Senior management owns the business risk decision, security owns control design and assurance, and IT owns implementation and operations. If any one of those functions is missing, the organisation usually ends up with a gap between policy, product settings, and what the help desk actually permits.

That gap matters most where OTP was being used as a convenience layer rather than a resilient control. A ban pushes teams toward phishing-resistant authentication, tighter recovery, and stronger session and device handling. If ownership sits only inside operations, the program often optimises for ticket closure instead of fraud resistance and auditability.

What part of the authentication lifecycle must be governed together

Ownership is not just about who approves the new sign-in method. It also covers binding the authenticator to the right user, managing fallback and recovery, setting step-up rules, and deciding what telemetry proves the control is working. Those pieces form one chain, and the chain is only as strong as its weakest handoff.

This is why login, account recovery, and monitoring should be treated as one governed process. A regulator does not care whether the weakness sits in the primary factor, the reset path, or the support workflow if the outcome is the same: an attacker can still get in. That is also why password reset rules, help desk scripts, and exception handling belong in the same ownership model as the sign-in product itself.

For teams migrating away from OTP, the key question is whether the replacement is genuinely phishing-resistant and whether fallback paths preserve that resistance. A passkey, certificate, or other stronger method can still fail if recovery returns the user to an easier-to-abuse path. The owner must therefore understand both the authentication mechanism and the recovery exception.

How to draw the accountability line without creating a handoff trap

Ownership should be explicit enough that no group can say it only provides a component. Senior management should approve the risk posture and exception tolerance. Security should define acceptable authenticators, recovery constraints, logging requirements, and review thresholds. IT should operate the platforms, enforce configuration, and prove that changes were applied consistently.

The practical test is whether one named owner can answer three questions: what is allowed for login, what happens when a user loses access, and how the organisation will know the control is working. That owner may delegate tasks, but not accountability. If the answer depends on several committees or on ad hoc support decisions, the control is too fragmented for a regulated authentication environment.

For workforce sign-in programs, a useful benchmark is to align the ownership model with established identity guidance on phishing-resistant authentication, recovery, and assurance levels. NIST SP 800-63 Digital Identity Guidelines is useful here because it ties authenticators, assurance, and recovery to a coherent policy model rather than isolated product choices.

Risk and Threat Considerations

When OTP is banned, the main risk is not merely non-compliance, it is replacement drift. Teams may disable one weak factor but leave recovery, help desk verification, or session handling weak enough that attackers can still take over accounts. That is especially dangerous where a fraudster only needs one exception path to bypass the intended control.

Failure mechanism: Fragmented ownership lets different teams optimise different parts of the chain, so a strong login method is undermined by weak resets, unenforced exceptions, or poor monitoring. Attackers then target the weakest operational path rather than the primary authenticator.

Impact: The result is account takeover, client loss, failed audits, and a false sense of control because the organisation believes it has “fixed” OTP while the recovery path remains exploitable.

Practitioner Guidance

What to prioritise: Assign one accountable owner for the full authentication control chain, then name the supporting security and IT owners under that decision. The owner should be able to approve acceptable authenticators, recovery limits, and escalation rules without waiting on separate teams to reconcile their own priorities.

What to verify: Check that the recovery process is at least as strong as the primary login method, that exceptions are time bound, and that monitoring can detect fallback abuse, repeated reset attempts, and unusual enrolment changes. If you cannot evidence those three points, the ownership model is not yet defensible.

Common mistake: Treating “who runs the IAM tool” as the same thing as “who owns authentication risk.” Tool administration is operational, but regulated auth risk is a governance decision that spans policy, control design, and loss prevention.

Practitioner takeaway: In a post-OTP environment, the owner is the person or function that can keep login, recovery, and monitoring aligned under one risk decision, not the team that happens to administer the platform.

Related resources from NHI Mgmt Group

• Who should own authentication risk decisions when security, compliance, and development teams all touch the login flow?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?