A restricted authenticator is a method that guidance treats as limited or higher risk in certain use cases. In this article, SMS-based and public switched telephone network based authentication fall into that category, which means organisations should plan alternatives rather than depend on them as a universal default.
What Makes a Restricted Authenticator “Restricted”
A restricted authenticator is not a universally banned method, it is a method that guidance treats as limited, higher-friction, or less suitable in some contexts. The restriction usually reflects a weaker assurance profile, greater exposure to social engineering, or operational constraints that make it a poor default for higher-value access.
In practical terms, the label tells you to treat the authenticator as conditional. SMS-based and public switched telephone network based authentication may still appear in some user journeys, but they should not be assumed to be equally trustworthy across all risk levels or all populations of users.
Why SMS and PSTN-Based Authentication Are Treated Cautiously
SMS and PSTN are convenient because they are widely available and simple to deploy, but convenience is not the same as strength. These channels depend on telephony infrastructure, phone-number ownership, and delivery paths that are outside the control of the application, which creates avoidable exposure when they are used as a primary factor or as the only fallback.
The key issue is not that these methods never work, but that they are easier to undermine than stronger phishing-resistant options. A restricted authenticator often signals that the organisation should reserve it for lower-risk scenarios, temporary recovery, or compatibility cases rather than treating it as the preferred long-term control.
For a more durable baseline, NIST SP 800-63 Digital Identity Guidelines explains authenticator assurance and the relative strength of different authentication methods.
Where Restricted Authenticators Fit in Authentication Design
Restricted authenticators belong in the design conversation, not just the policy document. Their role should be considered alongside account recovery, step-up authentication, backup factors, and user populations that may not be able to use stronger methods consistently.
This is especially important when a system supports both low-risk and high-risk actions. An authenticator that may be acceptable for routine access can become inappropriate when the same session can later be used for privileged transactions, sensitive data access, or account changes.
Practitioners should also remember that a restricted authenticator can create uneven security if it becomes the de facto fallback for everyone. That usually happens when stronger methods are optional but the weaker method is always available, easy to select, or embedded too deeply in the recovery flow.
When that design problem appears, the strongest response is usually to compare the fallback path against the actual access risk, then prefer stronger methods wherever the user journey permits. Guidance on OWASP Cheat Sheet Series is useful for implementation details around authentication and session handling.
Examples, Boundaries, and Common Misunderstandings
The most common misunderstanding is to treat “restricted” as a synonym for “forbidden.” That is too rigid. The better interpretation is that the method has recognized limits and should be used with restraint, especially where the consequence of compromise is high or where stronger methods are available.
Another mistake is to assume that an authenticator is safe simply because it is familiar to users. Familiarity can improve adoption, but it does not remove risks such as number compromise, social engineering, channel interception, or weak recovery processes.
For teams looking to align practice with modern authentication expectations, the broader control principle is to prefer methods with better resistance to phishing and account takeover. In that respect, the NIST AI Risk Management Framework is not the relevant authority here, but NIST SP 800-63 Digital Identity Guidelines remains the key reference for understanding why some authenticators are treated as lower assurance than others.
Risk and Threat Considerations
Restricted authenticators create exposure when organisations rely on them as a default path to access. The main concern is not just weaker authentication, but the downstream effect on account takeover, recovery abuse, and users becoming dependent on a method that is easier to redirect or undermine.
Failure mechanism: An attacker exploits the weaknesses of a limited channel, for example by targeting phone-number control, messaging interception, or user deception, then uses that access path to reach account recovery or session entry.
Impact: The result can be unauthorized access, privileged account compromise, or a recovery flow that becomes easier to abuse than the original login method.
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, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL/AAL/FAL — Digital Identity Assurance Levels and Authenticator Assurance | Defines authenticator strength and assurance levels for restricted methods. |
| Recommendation — Use assurance levels to prefer stronger authenticators over SMS or PSTN for higher-risk access. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Inventory of Accounts | Restricted authenticators affect how accounts are protected and recovered. |
| Recommendation — Limit weaker fallback authenticators for accounts with greater access sensitivity. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Restricted authenticators are an authentication-control choice within access governance. |
| Recommendation — Align authentication methods to access risk and avoid defaulting to lower-assurance factors. | ||
Practitioner Guidance
Why practitioners should care: If a method is classed as restricted, the operational question is where it still belongs, not whether it is convenient. Use it only when the access risk, recovery need, and user constraint justify the trade-off, and avoid letting it become the universal fallback for high-value accounts.
Common misunderstanding: Teams often assume a familiar phone-based factor is “good enough” because users recognize it and it reduces support friction. In reality, the control decision should be driven by assurance and abuse resistance, not by convenience alone.
Practitioner takeaway: Treat restricted authenticators as bounded-use methods, then steer primary access and sensitive recovery paths toward stronger authentication options wherever possible.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
