Is Silent Network Authentication a Restricted Authenticator Under SP 800-63-4?

No. Silent network authentication is not a restricted authenticator under NIST SP 800-63B-4 — and the reason is not that it passed a test. SP 800-63B-4 names exactly one restricted authenticator, “the use of the PSTN for out-of-band authentication,” and its authenticator taxonomy is closed at seven enumerated types. Carrier-network verification is none of the seven. It is not restricted because it is not an authenticator in the document’s terms at all.

This post is written against SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, final, July 2025, with the version-history stamp 07/31/25 on the CSRC publication record (CSRC, SP 800-63B-4, retrieved 2026-08-18). Every quotation below is lifted from the published text with its section number. Where NIST is silent, the silence is stated as a finding rather than filled in.

Key Takeaways

• SP 800-63B-4 §3.2.9 states, verbatim: “At the time of publication of these guidelines, there is one restricted authenticator: the use of the PSTN for out-of-band authentication, as described in Sec. 3.1.3.3.” That is the whole list (SP 800-63B-4 §3.2.9, retrieved 2026-08-18).
• The authenticator taxonomy is closed. §2.1.1 enumerates the permitted types — password, look-up secret, out-of-band device, single-factor OTP, multi-factor OTP, single-factor cryptographic, multi-factor cryptographic — with no residual or catch-all category (SP 800-63B-4 §2.1.1, retrieved 2026-08-18).
• The governing sentence is not in §3.2.9. It is in the Section 2 preamble: “The use of potential fraud indicators prior to or during the authentication process does not impact or change the AAL of a transaction or substitute for an authentication factor” (SP 800-63B-4 §2, retrieved 2026-08-18).
• SP 800-63B-4 does not describe, permit, prohibit, or classify carrier-network verification anywhere. The word “carrier” in the telecommunications sense does not appear in the volume; “SIM” appears exactly twice, neither time as an authentication event.
• Carrier records do have a defined home in the suite — as identity evidence during proofing. SP 800-63A-4 Appendix A.1 Table 4 lists a phone account as FAIR evidence, the lowest of NIST’s three strength tiers (SP 800-63A-4, retrieved 2026-08-18).
• Restricted does not mean banned, and unrestricted does not mean credited. SP 800-63B-4 states no effective date, compliance deadline, or transition period for federal agencies; do not plan against one that is not in the text.

On this page: the closed taxonomy · what is actually restricted · the four obligations · the governing sentence · the nearest adjacent text · where carrier records belong · phishing resistance · your risk assessment · three document-level traps · how this was sourced · FAQ · wrap-up

The Seven Authenticator Types, and Why the List Is Closed

The question “is this a restricted authenticator?” has a prerequisite: is it an authenticator type at all?

SP 800-63B-4 answers that by enumeration, and the cleanest normative statement is in §2.1.1, because AAL1 admits every type. Verbatim: “AAL1 authentication SHALL use any of the following authentication types, which are further defined in Sec. 3:” — followed by password (§3.1.1), look-up secret (§3.1.2), out-of-band device (§3.1.3), single-factor OTP (§3.1.4), multi-factor OTP (§3.1.5), single-factor cryptographic authentication (§3.1.6), and multi-factor cryptographic authentication (§3.1.7) (SP 800-63B-4 §2.1.1, retrieved 2026-08-18).

There is no eighth entry. No “network authenticator,” no “possession-of-number authenticator,” no residual category into which an unnamed mechanism falls by default. The glossary defines authenticator type as “A category of authenticators with common characteristics, such as the types of authentication factors they provide and the mechanisms by which they operate,” and authenticator as “Something that the subscriber possesses and controls (e.g., a cryptographic module or password) and that is used to authenticate a claimant’s identity.”

An operator’s assertion that a phone number is bound to the data session that originated a request is not something the subscriber possesses and controls. It is something a third party knows about the network. That is a different kind of object, and SP 800-63B-4 does not have a slot for it.

State the consequence carefully, because this is where most write-ups overreach: any claim that carrier-network verification “is” or “is not” a restricted authenticator is an extrapolation from a document that does not address the mechanism. What is not an extrapolation is the negative finding — the taxonomy is closed, the restricted list has one entry, and neither includes it.

What Is Restricted Is a Channel Inside a Type, Not the Type

Readers who arrive at “restricted authenticator” usually assume the restriction lands on SMS-shaped mechanisms broadly. It lands more narrowly than that.

§3.2.9 says, verbatim: “To account for these changes in authenticator performance, NIST places additional restrictions on authenticator types or specific classes or instantiations of an authenticator type. Although they represent a less secure approach to multi-factor authentication, restricted authenticators remain necessary for some government-to-public applications. At the time of publication of these guidelines, there is one restricted authenticator: the use of the PSTN for out-of-band authentication, as described in Sec. 3.1.3.3.”

§3.1.3.3 scopes it the same way in its opening sentence: “Use of the PSTN for out-of-band verification is restricted as described in this section and SHALL satisfy the requirements of Sec. 3.2.9.”

Three things follow. The out-of-band type is not restricted — out-of-band devices remain permitted at AAL1 and, at AAL2, as one of the physical authenticators that may be combined with a password or a biometric comparison, and multi-factor out-of-band authenticators are independently permitted at AAL2 (SP 800-63B-4 §2.2.1, retrieved 2026-08-18). The PSTN is not restricted in the abstract either — it is restricted in the role of carrying an out-of-band secret. And the glossary anticipates exactly this shape: a restricted authenticator is “An authenticator type, class, or instantiation that has additional risk of false acceptance associated with its use and is therefore subject to additional requirements.”

The document also supplies no self-assessment test. §3.2.9 says NIST places the restriction; it gives no criterion, threshold, or procedure by which an implementer could classify a mechanism NIST has not named. If you were hoping to run carrier verification through a checklist and get a verdict, there is no checklist to run.

The Four Obligations That Attach to a Restricted Authenticator

Most readers land on this question because they want to know whether a specific compliance burden applies to them. Here is the burden, so you can confirm it does not.

§3.2.9 states: “Because the subscriber may be exposed to additional risks when an organization accepts a restricted authenticator and the subscriber may have a limited understanding of and ability to control those risks, the CSP SHALL do all of the following:” — and the operative word in the text is all, not any.

There is a fifth requirement people miss, and it is a SHALL NOT aimed at the relying party: “It is the RP’s responsibility to determine the level of acceptable risk for their systems and associated data, define any methods for mitigating excessive risks, and communicate those determinations to the verifier. If the RP determines that the risk to any party is unacceptable, the restricted authenticator SHALL NOT be used, and an alternative authenticator type SHALL be used.”

None of these attach to carrier-network verification, because none of them are triggered by anything other than the one named restricted authenticator. If you still send SMS one-time passwords over the PSTN anywhere in your stack — including as the fallback behind a silent check — all five apply to that path, and adding a network-verification primary does not remove them. The economics and design of that fallback path are their own subject; the assurance question is settled here.

The Sentence That Actually Governs the Question

If carrier-network verification is characterised as a signal about the session rather than an authenticator, the controlling text is not §3.2.9 at all. It is the preamble to Section 2, and it is unambiguous.

“At all AALs, indicators of potential fraud, including applicable indicators described in Sec. 5.3, MAY be used to lower the risk of misauthentication. For example, authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls. CSPs or verifiers SHALL assess their use of indicators of potential fraud for efficacy and to identify and mitigate potential negative impacts on their user populations. CSPs or verifiers SHALL include fraud indicators in the authentication privacy risk assessment. The use of potential fraud indicators prior to or during the authentication process does not impact or change the AAL of a transaction or substitute for an authentication factor.”

— SP 800-63B-4, Section 2 introduction (source, retrieved 2026-08-18)

That final sentence is the answer to a question most implementers are actually asking. It does not matter how good the signal is. A carrier assertion consulted before or during authentication does not raise the AAL and does not stand in for a factor.

The signal’s family is identifiable in the document. §5.3, Session Monitoring, lists the session characteristics that MAY be evaluated: “Usage patterns, velocity, and timing,” “Behavioral biometric characteristics (e.g., typing cadence),” “Device and browser characteristics (e.g., accepted languages),” “Geolocation,” and “IP address characteristics (e.g., whether the IP address is in a block known for abuse).” Carrier telemetry is not on that list either, but that is the list its family belongs to — network-derived attributes, framed as fraud detection, explicitly not as authentication.

Revision 4 made this framing deliberate. The change log records: “Section 2: Describes the use of fraud indicators rather than pre-authentication checks.”

The Nearest Adjacent Text: SIM Authentication as a Precondition

SP 800-63B-4 does contemplate a device authenticating itself to a mobile network. Once. And the role it assigns is precise.

§3.1.3.1 lists three ways an out-of-band authenticator SHALL uniquely authenticate itself to the verifier. The second is: “Authenticate to a public mobile telephone network using a SIM card or equivalent secret that uniquely identifies the subscriber. This method SHALL only be used if a secret is sent from the verifier to the out-of-band device via the PSTN (i.e., SMS or voice) or an encrypted instant messaging service” (SP 800-63B-4 §3.1.3.1, retrieved 2026-08-18).

Read the conditional. SIM-to-network authentication is recognised as a real mechanism, but only as the way the channel endpoint identifies itself, and only when a secret then travels over that channel. It is a precondition for delivering a secret, never the authentication event.

That matters because out-of-band authentication is defined around a secret in the first place: “Out-of-band authentication uses a short-term secret generated by the verifier. The secret securely binds the authentication operation on the primary and secondary channels and establishes the claimant’s control of the out-of-band device” (§3.1.3). Both permitted flows are transfers of that secret between channels, and Revision 4 removed the approval-only variant precisely because it did not prove the subject was “actively participating in the session with the verifier.”

A silent check has no secret and no claimant transfer step. It cannot be an out-of-band authenticator on the document’s own definition — which is another route to the same conclusion.

The one other place SIM appears is §3.1.3.3: “Verifiers SHOULD consider risk indicators (e.g., device swap, SIM change, number porting, other abnormal behavior) before using the PSTN to deliver an out-of-band authentication secret.” Note the role. Exactly the carrier-derived signals that network APIs expose are named here — as inputs to a risk decision preceding an SMS, at SHOULD level, not as an authenticator. That is the whole of NIST’s treatment of carrier data in the authentication volume.

Where Carrier Records Do Have a Home: Identity Proofing

The constructive half of the answer is in a different volume. The SP 800-63 suite does model mobile network operator data — as identity evidence.

SP 800-63A-4 recognises a phone account as evidence whose issuance followed formal procedures: “There is a reasonable expectation that the issuing source of the evidence confirmed the claimed identity by following formal procedures designed to provide assurance that the claimed identity is associated with the subject, such as evidence issued by financial institutions that have customer identity verification obligations under the Customer Identification Program (CIP) rule or procedures for establishing a mobile phone account with a mobile network operator (MNO).”

It also acknowledges that this evidence has no physical form to inspect: “For some digital evidence (e.g., MNO/phone accounts), there is not a physical piece of evidence that can be validated visually or physically. Authenticity is confirmed by validating the identity attributes associated with that account and phone number with an issuing or credible source, such as by validating a digitally signed assertion from the issuer or querying an attribute validation service with access to that account information.”

§4.2.6, the IAL2 digital evidence pathway, then lists among approved verification methods for FAIR evidence: “Confirming the applicant’s ability to return a confirmation code delivered to a validated digital address associated with the digital evidence (e.g., MNO/phone account)” (SP 800-63A-4 §4.2.6, retrieved 2026-08-18).

Two details set expectations correctly. First, a phone account is FAIR strength — the lowest of NIST’s three evidence tiers, below STRONG and SUPERIOR. Second, the informative Table 4 in Appendix A.1 lists “Confirm presence of user account with MNO” under validation, and requires verification separately, through “Demonstrated possession through enrollment code” or “Demonstrated possession via an AAL2 authentication event and an FAL2 federated assertion.”

So the correct sentence for your architecture document is: a carrier query is a validation input to identity proofing at FAIR strength, not an authentication factor. That is a real, defined role. It is simply not the one vendors imply when they market the mechanism against SMS OTP.

Phishing Resistance Is a Separate Question

Do not let the restriction question absorb the phishing-resistance question. They are independent, and the second one is where an AAL2 design actually gets stuck.

§2.2.2 states: “Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2, as described in Sec. 3.2.5. Federal agencies SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems.” Table 1 in §2.5 summarises the same, non-normatively: phishing resistance is Not required at AAL1, Recommended; Must be available at AAL2, and Required at AAL3.

What qualifies is a closed statement in §3.2.5: “Phishing resistance requires single- or multi-factor cryptographic authentication. Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated.”

Both recognised methods — channel binding (§3.2.5.1) and verifier name binding (§3.2.5.2) — require the authenticator itself to perform an approved cryptographic operation binding its output to a negotiated channel identifier or an authenticated verifier identifier. A network-layer assertion about a subscriber satisfies neither, because nothing in it is bound to the site the user is actually on. We work through that argument in full in SNA and phishing resistance.

The clean summary: removing the SMS round trip removes an interception surface. It does not produce a cryptographic binding, and phishing resistance in SP 800-63B-4 is defined entirely in terms of one.

What to Write in Your Risk Assessment

If you are deploying carrier verification and someone has asked for the NIST position, this is the shape of an honest answer.

1. State the negative finding precisely. “SP 800-63B-4 does not define, permit, prohibit, or classify network-layer verification of a subscriber’s device. The volume’s authenticator taxonomy (§3.1) is closed at seven types and this mechanism is not among them.” That is defensible; “it is not restricted, therefore it is fine” is not.
2. Classify it yourself, and say which classification you chose. The two defensible readings are a fraud indicator under the Section 2 preamble, or a validation input to identity evidence under SP 800-63A-4 §4.2.6. Both carry consequences: the first cannot change an AAL, the second is FAIR-strength evidence requiring separate verification.
3. Do not claim AAL credit. Quote the Section 2 sentence in the document itself. It pre-empts the argument better than any summary you can write.
4. Name your actual authenticators. Whatever supplies your AAL has to come from §3.1. If the answer is a password plus an out-of-band device over the PSTN, then §3.2.9’s five obligations are live for you regardless of what the silent path does.
5. Record the classification obligation. §4.1 requires that “The CSP SHALL determine the characteristics of the authenticator being bound (e.g., single-factor versus multi-factor, phishing-resistant or not) so that verifiers can assess compliance with the requirements at each AAL.” An untyped mechanism cannot satisfy that, which is itself the reason to keep it out of the authenticator column.
6. Cross-check other regimes separately. A NIST conclusion is not a PSD2 conclusion — the European position on possession elements is a different analysis with a different answer, covered in does SNA satisfy PSD2 SCA.

The mechanism itself, what the operator compares and what it genuinely proves, is documented in silent network authentication: how carrier-verified phone possession actually works.

Three Traps in How People Cite This Document

Trap one: “SP 800-63B §5” is Revision 3. Revision 4 removed the Purpose, Definitions, and Abbreviations sections and renumbered. Appendix C states it outright: “Removes Purpose, Definitions, and Abbreviations numbered sections and renumbers sections accordingly. The section numbers referenced below are the new section numbers.” Authenticator types moved from §5 to §3.1. A citation to §5 for authenticator types is a citation to the superseded edition, which the CSRC record lists as “Supersedes: SP 800-63B (03/02/2020).”

Trap two: the VoIP prohibition is gone. Revision 3 banned VoIP numbers for out-of-band authentication. Revision 4’s change log records: “Section 3.1.3.1: Removes the prohibition on the use of VoIP phone numbers for out-of-band authentication.” VoIP now appears affirmatively in §3.1.3.2 — “The verifier MAY additionally display an address, such as a phone number or VoIP address, for the claimant to use in addressing its response to the verifier.” Guidance written before July 2025 gets this wrong.

Trap three: restricted does not mean prohibited, and regulators have not banned SMS OTP. §3.2.9 says restricted authenticators “remain necessary for some government-to-public applications.” NIST also reserves the right to move the line: “Consistent with the discussion of restricted authenticators in Sec. 3.2.9, NIST may adjust the restricted status of out-of-band authentication using the PSTN based on the evolution of the threat landscape and the technical operation of the PSTN” (§3.1.3.3). Outside the United States the direction of travel is de-monopolisation rather than prohibition: the Reserve Bank of India’s Authentication mechanisms for digital payment transactions Directions, 2025 (RBI/2025-26/79, issued 25 September 2025, effective 1 April 2026) keep “SMS based OTP” on the permitted factor list while opening the door to alternatives (RBI notification, retrieved 2026-08-18), and the European Banking Authority’s Single Rulebook Q&A 2019_4671, finalised 5 March 2021, holds that “a one-time password sent via SMS would constitute a possession element and therefore should comply with the requirements under Article 7 of the Delegated Regulation” (EBA Q&A 2019_4671, retrieved 2026-08-18). The channel is being pushed out of the centre, not outlawed. For the security case that motivates the shift, see what are OTPs in messages: SMS one-time passwords, risks, and safer alternatives.

How This Guide Was Sourced

Who wrote this and how to check it: this guide was written and reviewed by the MojoAuth engineering and content team, which builds authentication infrastructure for consumer and agent-facing applications; the team’s published work is listed under MojoAuth blog authors. Disclosure: MojoAuth builds Silent Auth, a carrier-network verification product in the category this post examines. Every limitation described here applies to our own implementation as much as to anyone else’s, and we document them because a verification layer you cannot reason about is one you cannot deploy safely. That commercial interest cuts against the conclusion below, which is drawn from the standard’s text rather than from our product positioning. Corrections reach the team through MojoAuth.

Document revision. Every normative quotation comes from the Revision 4 suite, all four volumes final, published July 2025: SP 800-63B-4 (Authentication and Authenticator Management), SP 800-63A-4 (Identity Proofing and Enrollment), and the SP 800-63-4 base volume, all retrieved 2026-08-18. Publication status was confirmed against the CSRC record for SP 800-63B-4, which carries the version-history stamp 07/31/25 for the final revision and “Supersedes: SP 800-63B (03/02/2020)”; the PDF’s publication history records “Approved by the NIST Editorial Review Board on 2025-05-30.”

Pin your section numbers, not your memory. The HTML edition numbers its headings with CSS counters and emits no numerals into the markup, which is why several secondary write-ups cite Revision 3 numbering. Section numbers here were read from the authoritative PDF’s table of contents and body headings, then matched against literal heading strings. Cite SP 800-63B-4 in NIST’s own identifier style — volume letter, then revision number — not “800-63B rev 4.”

On compliance dates. SP 800-63B-4 states no effective date, compliance deadline, or transition period. Its Authority section binds only by reference: “This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014… This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.” Whether any OMB memorandum issued after July 2025 sets an agency deadline specific to Revision 4 is not verifiable from the NIST corpus, and no deadline is asserted anywhere in this post.

On the negative findings. Statements that a term does not appear in SP 800-63B-4 rest on full-text searches of the published volume conducted 2026-08-18 for carrier, mobile network operator, MNO, data session, silent, network-layer, SS7, signaling, and header enrichment. “SIM” occurs exactly twice, both quoted above. No vendor blog, analyst note, or third-party summary was consulted for any claim in this post.

No MojoAuth telemetry is used in this guide. Every figure above is external and linked.

Frequently Asked Questions

Is silent network authentication a restricted authenticator under SP 800-63-4?

No. SP 800-63B-4 §3.2.9 names one restricted authenticator — “the use of the PSTN for out-of-band authentication, as described in Sec. 3.1.3.3” — and carrier-network verification is not it. The deeper reason is that the §3.1 authenticator taxonomy is closed at seven types and does not include a network-verification category, so the mechanism is not an authenticator in the document’s terms and the restriction question does not reach it.

Does that mean it is approved by NIST?

No, and this is the trap. SP 800-63B-4 does not permit it either. The document does not address it. Being outside the taxonomy means no §3.2.9 obligations attach and no AAL credit accrues — the same fact cuts both ways.

Can a carrier check count as the possession factor at AAL2?

Not on the document’s text. §2.2 requires “Proof of possession and control of two distinct authentication factors through the use of secure authentication protocols,” and §2.2.1 lists which types may supply them. Separately, the Section 2 preamble states that “The use of potential fraud indicators prior to or during the authentication process does not impact or change the AAL of a transaction or substitute for an authentication factor.” A signal about the session is not a factor.

Which section covers authenticator types — §3.1 or §5?

§3.1 in Revision 4. §5 was the location in Revision 3, which the CSRC record lists as superseded. Appendix C of Revision 4 records the renumbering: “Removes Purpose, Definitions, and Abbreviations numbered sections and renumbers sections accordingly.”

Where does NIST put mobile operator data, then?

In identity proofing. SP 800-63A-4 treats an MNO/phone account as digital identity evidence, listed at FAIR strength in the informative Table 4 of Appendix A.1, with “Confirm presence of user account with MNO” as a validation step. §4.2.6 lists confirmation-code return to that account among approved verification methods for FAIR evidence at IAL2. It is a proofing input, not an authenticator.

Is SMS OTP banned under Revision 4?

No. It is restricted, which §3.2.9 defines as subject to additional requirements, and the section says restricted authenticators “remain necessary for some government-to-public applications.” Revision 4 also removed the Revision 3 prohibition on VoIP numbers for out-of-band authentication. If you keep an SMS path, the four CSP SHALL items plus the RP-side SHALL NOT trigger apply to it.

Conclusion

The counter-intuitive part of this answer is that “not restricted” is the weaker verdict, not the stronger one. A restricted authenticator is inside the model: it has a type, it counts toward an AAL, and it comes with four CSP obligations and an RP-side veto that you can actually implement. A mechanism outside the taxonomy has no obligations because it has no standing.

So the accurate statement for a compliance document is narrow and quotable. SP 800-63B-4 has one restricted authenticator and it is the PSTN in an out-of-band role. The taxonomy is closed at seven types. Carrier-network verification is not among them, is not excluded from them by name, and is not assessed anywhere in the volume. If you characterise it as a signal — which is where its family sits, alongside geolocation and IP characteristics in §5.3 — then the Section 2 preamble governs, and it neither changes an AAL nor substitutes for a factor.

The constructive move is to stop arguing about the authenticator column. Put the carrier query where NIST already has a slot for it: SP 800-63A-4 §4.2.6, as a FAIR-strength identity evidence input during proofing, and keep your AAL sourced from §3.1 types. For the wider comparison of what each primitive is actually for, start with silent network authentication vs. SMS OTP vs. passkeys.