KBA for Form 8879: Designing Identity Checks Clients Finish
Verdocs Team
When a taxpayer signs Form 8878 or 8879 remotely, IRS Publication 1345 sets the identity rules. Tax software has no say in whether knowledge-based authentication (KBA) is required, or in what happens after three failed attempts.
Software does decide what the client experiences: what they are told before the questions start, what they see when something goes wrong, how a joint return with two signers is handled, and whether the firm can tell which returns are actually ready to file. This post covers those decisions. For the full list of recording and storage requirements, see Product Requirements for Remote Signing of IRS Forms 8878 and 8879.
This is product guidance, not legal advice. Confirm your obligations with counsel.
What Publication 1345 requires, and what it recommends
Publication 1345 (Rev. 12-2025) separates requirements from recommendations. Keeping them apart matters when deciding what the product must enforce and what it should simply do well.
| Item | Status | Where |
|---|---|---|
| Remote signing requires identity verification, including KBA, at the NIST level the publication cites | Required | Pages 16 to 17 |
| On a joint return, each taxpayer must be identified and authenticated separately | Required | Page 16 |
| After three failed KBA attempts, the ERO must obtain a handwritten signature on the form | Required | Page 17 |
| Software must disable identity verification after three attempts | Required of software developers | Page 29 |
| Identity verification must take place in a secure portal | Required of software developers | Page 29 |
| Software must not allow the return to be transmitted until Form 8879 is signed | Required of software developers | Page 30 |
| Before verification begins, tell taxpayers about the use of third-party data and any "soft inquiry" | Recommended ("should") | Page 30 |
| Tell taxpayers the IRS will not see their credit report, and the verification provider will not see their tax information | Recommended ("should") | Page 30 |
The IRS e-file signature FAQ adds that identity verification must be completed each time a taxpayer electronically signs Form 8878 or 8879, with a limited exception for in-person signing where the ERO has a multi-year relationship with the taxpayer. For how the NIST level cited in the publication relates to KBA, see Is Knowledge-Based Authentication Enough for Remote Signing?
Prepare the client before the first question
A client who expects to click "sign" and instead sees questions about past addresses may assume something is wrong. Publication 1345 recommends explaining the process before verification starts. A short notice in the signing request, repeated on the screen before the first question, can cover:
- Why the questions appear. The IRS requires identity verification when Form 8878 or 8879 is signed electronically and remotely.
- Where the questions come from. They are drawn from third-party records, such as credit bureau data.
- What the check leaves behind. The process may create a "soft inquiry" on the client's credit report. Say whether your provider's process does, and what effect it has, in plain terms.
- What stays separate. The IRS does not see the client's credit report, and the verification provider does not see the client's tax information.
The request should come from the firm, using its own name and email domain, and lead to a page the client recognizes as the firm's. A request for the last four digits of a Social Security number looks very different inside a familiar portal than on an unfamiliar site.
Other documents need their own evaluation
Publication 1345's KBA rules are written for Forms 8878 and 8879. That does not settle what other documents need. Engagement letters, consents to use or disclose tax return information, payment authorizations, and organizers each need to be evaluated on their own, under whatever requirements apply to them and the firm's own policy. Some carry rules of their own.
The design benefit of making that evaluation explicit is that KBA is not applied out of habit. A client who answers identity questions once, for the form that requires them, is more likely to finish than one asked repeatedly through the season.
The failure path must be enforced
Publication 1345 makes the failure path a software requirement, not a design preference. Two things have to be enforced by the system itself, not only shown in a dashboard:
- Identity verification stops after three failed attempts. This is the requirement. Our recommendation for enforcing it: do not let a fresh signing request become a way to get three more tries. One approach is to track attempts against the taxpayer and the form rather than the individual request. Publication 1345 states the limit; it does not prescribe this design, so confirm your approach with counsel.
- The return cannot be transmitted until Form 8879 is signed. This is also a requirement. We recommend enforcing it in the filing workflow, as a block on transmission, so a return cannot go out because someone misread a status.
ID verification is not a substitute here. The publication names a handwritten signature as the fallback after failed KBA.
The handwritten path does not have to mean an office visit. Publication 1345 allows the taxpayer to return the signed form by hand delivery, mail, private delivery service, fax, email, or an internet website (page 15). A secure upload in the firm's client portal fits within that list, so a client can print, sign, photograph or scan, and upload the same day.
Within those requirements, the interface should tell the client plainly what happens next, notify the preparer immediately, and provide the printable form.
A joint-return example
Maria and David file jointly. The tax platform sends Form 8879 with each spouse as a separate signer, each with their own KBA step, as Publication 1345 requires.
Maria passes KBA on Tuesday evening and signs. David misses questions on all three attempts, and identity verification is disabled for him.
The platform now shows each signer's status separately: Maria signed, David requires a handwritten signature. The return's status reads "Not ready: handwritten Form 8879 needed from David," and transmission stays blocked. Maria's completed signature does not make the return look ready.
The firm sends David the form through the portal, and he uploads a handwritten signed scan the next morning. The upload does not make the return ready. Maria's electronic signature and David's handwritten scan are separate records, and attaching one to the other does not by itself complete the authorization. Transmission stays blocked until the firm has reviewed and accepted a complete Form 8879 with all required signatures under its approved procedure. Whether that procedure needs both spouses' handwritten signatures on one form is a question for the firm and its counsel to settle before filing season.
What the firm needs to see
A preparer managing hundreds of returns needs a status per signer, not just per return: sent, verified, signed, or verification failed and handwritten signature needed. That status should update from events rather than from someone checking email, and the transmission block should read from the same data.
What Verdocs provides, and what your platform builds
Verdocs provides embedded, white-label eSignature for tax and accounting platforms:
- Authentication set per recipient, so each spouse on a joint return can be a separate signer with their own KBA step. KBA is activated per account and runs through our partnership with GBG.
- The verification steps render inside the embeddable Verdocs signing component, under the firm's brand, and requests can be sent from the firm's own email domain.
- Verdocs enforces the three-attempt KBA limit. When a configured check fails, the signer cannot continue and is told to contact the sender.
- The platform can retrieve authentication failure status through an endpoint, and the
recipient_auth_failwebhook reports that a signer's check failed. Neither should be assumed to provide an attempt counter you can use to track attempts across separate requests. - Separate webhooks report signing activity: submitted, declined, and completed. These describe the signing process, not authentication results.
Your platform handles the response: the advisory text before verification, notifying the preparer, the handwritten-signature path and upload, any tracking across separate requests, the per-signer status the firm sees, and the block that prevents filing until the required authorization is complete. For how responsibility divides between the signing provider, the software company, and the firm, see Who Is Responsible for Compliance When eSignature Is Embedded in Tax Software?
See how this works for accounting and tax platforms, or schedule a demo to walk through your filing-season workflow with us.
