Is Knowledge-Based Authentication Enough for Remote Signing?
Verdocs Team
You shipped knowledge-based authentication because Publication 1345 requires it, and someone told you it satisfies the NIST requirement in the same paragraph. Then a customer's security reviewer asks which assurance level you meet, and you find that the two sentences in the IRS handbook do not obviously line up with each other.
They do not, and the reason is checkable in two clicks. This article sets out what each document says, labelled by kind: Required where Publication 1345 says must, Guidance where it says should, Reading where a conclusion depends on interpreting an ambiguous reference, Recommended practice for our engineering opinion, and Uncertain where the published sources do not settle it. Nothing here concludes that any particular combination of controls guarantees compliance, because no honest reading of these documents supports that.
What Publication 1345 actually requires
Required. Two things, in the same short section of IRS Publication 1345 (Rev. 12-2025).
First, KBA is not optional for these forms. The software "will enable the identity verification using knowledge-based authentication questions when an ERO uses tax preparation software to interact with the taxpayer for purposes of obtaining an electronic signature on Form 8878 or 8879." The software must record the taxpayer's passed KBA results, and if the taxpayer fails "after three attempts, then the ERO must obtain a handwritten signature."
Second, and separately: "The identity verification requirements must be in accordance with National Institute of Standards and Technology, Special Publication 800-63, Electronic Authentication Guideline, Level 2 assurance level and knowledge-based authentication or higher assurance level."
The first sentence is a clear instruction. The whole question is what the second one adds.
The document that sentence names was withdrawn in 2017
Required reading of a fact, not an interpretation. Electronic Authentication Guideline is the title of NIST Special Publication 800-63-2, published August 2013 and withdrawn on 22 June 2017. Current guidance is SP 800-63-4, Digital Identity Guidelines, July 2025, which supersedes SP 800-63-3 and splits assurance into three independently selected levels: identity proofing (IAL), authentication (AAL) and federation (FAL).
Uncertain. Publication 1345 does not say which version of SP 800-63 it means, and there is no single "Level 2" in the current framework. So "Level 2 assurance level" supports at least two defensible readings, and they lead to different places.
Reading A: Level 2 means what the cited document meant
In SP 800-63-2, the levels were overall assurance levels, and Level 2 was explicit: "Level 2 provides single factor remote network authentication." Multi-factor started at Level 3: "Level 3 provides multi-factor remote network authentication."
Under this reading one factor is sufficient, which is a considerably lower bar than most people assume when they hear "Level 2."
Two details complicate even this reading. SP 800-63-2 listed "Pre-Registered Knowledge Tokens" among the single-factor tokens permitted at Level 2, but a pre-registered knowledge token is something the subscriber registered in advance. Dynamic questions generated from credit records are not obviously the same thing, and that document treated credit-bureau style KBA as part of registration rather than as a token. And SP 800-63-2 was already skeptical of the method it permitted: knowledge-based techniques were "largely avoided because their security is often weak or difficult to quantify," and it noted that because the information is "private but not actually secret, confidence in the identity of an individual can be hard to achieve."
Reading B: Level 2 means AAL2 in the current guidance
SP 800-63B-4 on AAL2: "Proof of the possession and control of two distinct authentication factors is required." At AAL2, authentication "SHALL use either a multi-factor authenticator or a combination of two separate authentication factors." Where two single-factor authenticators are combined, the combination "SHALL include one physical authenticator (i.e., 'something you have')" from a listed set, "in conjunction with either a password or a biometric comparison."
KBA answers are neither a password nor a physical authenticator. Under this reading, they do not contribute to the count of two.
SP 800-63A-4 goes further on the proofing side: "Knowledge-based verification (KBV) or knowledge-based authentication SHALL NOT be used for identity verification." KBA survives in one place only, fraud management: "CSPs MAY employ KBV as part of its fraud management program."
One precision point that gets lost in summaries. NIST's "identity verification" is a term of art inside identity proofing, meaning the step that binds an applicant to validated evidence. It is not the same scope as the IRS's use of the same phrase. So the accurate statement is narrower than "NIST bans KBA": current NIST guidance excludes it from the proofing step and does not count it as an authentication factor, while the IRS requires it for these forms. Both documents are current, and neither resolves the other.
Why the obvious fix is not a switch
The intuitive move is to add an SMS one-time passcode and call it two factors. That is a real improvement in confidence, and it is not a compliance guarantee.
Required, in the current guidance. An out-of-band device is a permitted physical authenticator. But note what Reading B requires of the pairing: a physical authenticator plus a password or a biometric. KBA plus SMS OTP is a physical authenticator plus knowledge that is not a password, so it does not map cleanly onto the combination AAL2 states.
Two more constraints matter for anyone designing this. "Email SHALL NOT be used for out-of-band authentication," which is worth knowing because the emailed unique link is the default pattern in embedded signing and is sometimes described as a factor. And SMS is permitted but restricted: "Use of the PSTN for out-of-band verification is restricted," with duties to weigh risk indicators such as device swap, SIM change and number porting, to ensure "alternative authenticator types are available to all subscribers," and to document coverage limitations.
What each control does and does not establish
Reading. This table maps controls onto requirements. The right-hand column is the one to read carefully.
| Control | In Pub 1345 | In SP 800-63-4 | Does not establish |
|---|---|---|---|
| KBA via credit records | The KBA requirement, plus recorded passed results | Not a factor; barred from identity verification in proofing | Any AAL, alone |
| Emailed single-use link | Invitation delivery | Not permitted for out-of-band authentication | A factor of any kind |
| SMS one-time passcode | Not named | Out-of-band device, permitted but restricted | AAL2 alone, or paired with KBA under Reading B |
| Password or passphrase | Not named | The knowledge factor AAL2's pairing calls for | Anything, if signers hold no account |
| Passkey or authenticator app | Not named | Cryptographic authentication, single or multi-factor | That signers will complete it |
| Government photo ID check | The in-person element only | Proofing evidence, not authentication | A substitute for the required KBA |
Recommended practice. Do not try to win this argument with a control stack. Win it with documentation: for each control, record which Publication 1345 requirement it addresses, what NIST calls it, and what you are not claiming. A reviewer who sees that you know the difference will trust you more than one who sees a list of acronyms.
What this means for product teams
- KBA is required here, so build it. Whatever the assurance debate, Publication 1345 names KBA for Forms 8878 and 8879 and requires recording the passed results.
- Do not describe the emailed link as a factor. Current guidance is explicit that email is not permitted for out-of-band authentication.
- Add a second factor for the reasons it actually helps. Better confidence that the person holding the link is the taxpayer is worth having on its own merits. Label it that way internally rather than as a compliance fix.
- If you add SMS, build the duties with it. Alternative authenticator availability and SIM-swap or porting risk signals are part of the restricted status, not optional extras.
- Write down which reading you rely on. The ambiguity is in the source document. Your defensible position is a documented, reasoned choice, not a claim that the question is settled.
- Take this one to counsel. Which reading applies to you depends on your IRS role and your workflow. This is the article in the series where that advice is least optional.
Frequently asked questions
Does Publication 1345 require multi-factor authentication for signing Form 8879? It does not say so in those words. It requires KBA and requires identity verification to accord with "Special Publication 800-63, Electronic Authentication Guideline, Level 2 assurance level." The document with that title defined Level 2 as single-factor authentication; the current guidance's AAL2 requires two distinct factors. Publication 1345 does not say which applies.
If NIST says KBA cannot be used, how can the IRS require it? Both statements are narrower than they sound. Current NIST guidance excludes knowledge-based verification from the identity-verification step within identity proofing and does not treat KBA as an authentication factor. It does not prohibit the IRS from requiring KBA in its own program, and the IRS has not withdrawn that requirement.
Is KBA plus SMS OTP equal to AAL2? Not straightforwardly. AAL2's two-single-factor path requires a physical authenticator combined with a password or a biometric comparison. An SMS passcode is a permitted out-of-band physical authenticator, but KBA is not a password. Anyone telling you a specific pairing guarantees AAL2 is overstating what the document says.
Does using KBA mean our platform is compliant? Compliance is not a property of a control. It depends on which IRS roles your company holds, what your workflow does, and what your customers' obligations are. A vendor can tell you what a control is and what it records; only advice specific to your arrangement can tell you what it satisfies.
Where Verdocs fits
Verdocs is embedded signing infrastructure, so identity is a step we orchestrate rather than a dataset we hold. For KBA, the questions come from a third-party identity provider working from public records and the signer never leaves your product. Our authentication options are a ladder you choose per document, not a single setting; audit trails and identity verification for financial APIs sets out that ladder and what each rung records.
What we will not do is tell you that turning one of them on makes your product compliant with Publication 1345, because that depends on facts about your role and workflow rather than about our platform. If you are working through this, start a conversation, read the Form 8879 build spec, or see how we approach accounting and tax.
Sources
Read 2026-08-22. Revision dates are as printed on the documents.
- IRS Publication 1345, Authorized IRS e-file Providers of Individual Income Tax Returns, Rev. 12-2025, Catalog Number 64382J. Digital Identity Verification Requirements, Identity Verification and Identity Verification Failure: pages 16 to 17.
- NIST SP 800-63-4, Digital Identity Guidelines, Revision 4, July 2025, superseding SP 800-63-3. Scope, applicability, and the IAL, AAL and FAL structure.
- NIST SP 800-63A-4, Identity Proofing and Enrollment, Revision 4. The prohibition on KBV for identity verification, and its permitted use in fraud management.
- NIST SP 800-63B-4, Authentication and Authenticator Management, Revision 4. AAL2's two-factor requirement and permitted authenticator types, the prohibition on email for out-of-band authentication, and the restricted status of the PSTN at Section 3.1.3.3.
- NIST SP 800-63-2, Electronic Authentication Guideline, August 2013, withdrawn 22 June 2017. The document whose title Publication 1345 cites. Level 2 as single-factor authentication, the permitted Level 2 tokens, and its own assessment of knowledge-based authentication. Full text: NIST.SP.800-63-2.pdf.
- Form 8879, IRS e-file Signature Authorization, Rev. 01-2021. The ERO instruction to confirm the identity of the taxpayer.
This article is provided for general informational purposes and does not constitute legal, tax, security, or compliance advice. Requirements may vary depending on your organization's role, technology, and workflow.
