Product Requirements for Remote Signing of IRS Forms 8878 and 8879
Verdocs Team
An accounting customer asks whether your platform can collect electronic signatures on Form 8879, so their taxpayers stop printing, signing and scanning. It sounds like a two-week feature. Then you look for the requirements and find guidance written for e-file administrators, spread across two chapters of an IRS handbook.
There is a spec. IRS Publication 1345 (Rev. 12-2025) sets out nine requirements for software developers who enable electronic signatures on Forms 8878 and 8879, plus six data elements the software must record. Each point below is labelled: Required where the publication says must, Guidance where it says should, Recommended practice for our engineering opinion, Depends on role where the answer changes with which IRS role your company holds, and Uncertain where the sources do not settle it.
When these requirements apply
Required. The rules attach when a taxpayer signs Form 8878 or 8879 electronically and your software provides that capability. Publication 1345: "the software and the Electronic Return Originator (ERO) must meet certain requirements for verifying the taxpayer's identity."
A remote transaction is one where the taxpayer signs electronically and the ERO is not physically present. That is the shape of nearly every embedded signing flow, and four of the six recording requirements are remote-only.
What is out of scope matters when you scope the work: a remote-transaction electronic signature "does not include handwritten signatures on Forms 8878 or 8879 sent to the ERO by hand delivery, U.S. mail, private delivery service, fax, email or an Internet website." If your customers only upload signed PDFs today, you are not in this regime yet.
The nine requirements, as engineering requirements
All Required, from "Additional Requirements for Software Developers Enabling Electronic Signatures for Forms 8878 and 8879."
| Publication 1345 requirement | In a build | Typical owner |
|---|---|---|
| Provide six data elements to the ERO in an accessible format, with print capability | An ERO-facing evidence export, not an internal log | Signing platform |
| Follow the identity verification requirements | The identity step, and the hardest to reason about | Shared |
| Disable identity verification after three attempts | A hard counter, not a rate limit | Signing platform |
| Identity verification occurs in a secure portal | The identity step runs in your controlled surface | Signing platform |
| The signed electronic record is tamper-proof | Seal on completion, with signature linkage | Signing platform |
| Storage system has secure access controls | Attaches to whoever stores the form | Depends on role |
| Storage system has a retrieval system including an indexing system | Retrievable by taxpayer, form and year | Depends on role |
| Software can reproduce legible and readable hardcopies | A print path that still works in three years | Depends on role |
| No tax return transmission until Form 8879 is signed | An ordering constraint across two systems | Practice management platform |
The last four rows surprise teams. Three concern the storage system, which in an embedded arrangement is often not the signing vendor's. The ninth concerns transmission, which a signing vendor does not control at all.
The six elements the software must record
Required. "The software must record the following data," followed by: "The ERO must provide this information to the IRS upon request."
- Digital image of the signed form.
- Date and time of the signature.
- Taxpayer's computer IP address (remote only).
- Taxpayer's login identification, username (remote only).
- Identity verification: passed results of knowledge-based authentication, and for in-person transactions, confirmation that government photo identification was verified.
- Method used to sign the record, or a system log, or other audit trail reflecting completion of the signature process by the signer.
Element 6 reads as an either-or. A typed-name method string satisfies its letter; an audit trail is what you will want when someone asks about a signature from three filing seasons ago.
The field that assumes an account
Uncertain. Element 4 asks for the taxpayer's username, which presumes an account exists. Most embedded flows issue a single-use tokenised link from an email invitation and create no taxpayer account. Publication 1345 does not say what to record in that case, and we are not aware of published IRS guidance that resolves it.
Recommended practice: record a durable unique identifier for the signer session, document what it is and why, and be able to explain the mapping. Do not leave the field silently empty, and do not populate it with something that reads like an account when it is not. Worth raising with your own counsel rather than settling by analogy.
Three attempts, then paper
Required, as two requirements working together. Software must "disable identity verification after three attempts." And if the taxpayer fails the knowledge-based authentication questions after three attempts, "the ERO must obtain a handwritten signature on Form 8878 or 8879."
The failure path is not an error state, then. It is a mandatory fallback to paper, and it will fire: KBA fails for real people with thin credit files, recent moves and common names.
Recommended practice: design the exit before the happy path. When the counter trips, tell the taxpayer what happens next, notify the firm, and hand the ERO a printable form in the same action. A dead end reading "identity verification failed" turns one blocked return into a support ticket for your customer and a phone call for theirs.
The ordering constraint nobody owns
Required, and it crosses a system boundary. Software must not "allow tax return transmission until Form 8879 is signed." Form 8879's instructions to EROs are firmer: the ERO "must receive the completed and signed Form 8879 from the taxpayer before the electronic return is transmitted."
In a monolith this is an if. In an embedded arrangement it is a contract between two products: the practice management platform holds the transmit action, the signing platform knows whether the form is signed.
Recommended practice: make signed-state pull-verifiable, not only pushed. A webhook that fires once and is never retried is a weak foundation for a gate the IRS requires.
Two advisories you should show the taxpayer
Guidance, not requirement. A software developer should inform taxpayers about the use of third-party data and "soft inquiries" before identity verification begins, and should state that the IRS will not be given view of or access to the taxpayer's credit report, nor will the credit reporting company have access to their tax information.
Both are cheap to build and they answer the taxpayer's real worry, which is whether this affects their credit. Publication 1345 also states that a record check for signing purposes "does not require additional consents from the taxpayer beyond those obtained for preparing and filing their taxes," and does not violate Internal Revenue Code section 7216.
What varies by role and workflow
Depends on role. Publication 1345 allocates duties across five provider roles, and one company can hold several. The storage rows land wherever the form is stored. The ERO's own duties, including recording the taxpayer's name, Social Security number, address and date of birth for remote transactions, and Form 8879's instruction to "confirm the identity of the taxpayer(s)," stay with the firm.
If you white-label, one change in the current revision matters: Publication 1345 (Rev. 12-2025) added a section stating that providers who resell software, "e.g., rebranding, white label, etc.," are also considered by the IRS to be Intermediate Service Providers, a role carrying its own e-file application and EFIN obligations.
Uncertain. Requirement 2, "follow the identity verification requirements," is the one no checklist resolves. Publication 1345 requires knowledge-based authentication and also requires identity verification to accord with NIST Special Publication 800-63 at "Level 2 assurance level." That citation names a NIST document withdrawn in 2017, and current NIST guidance treats knowledge-based methods very differently. That is its own article, and no article should tell you a given combination of controls guarantees compliance.
What this means for product teams
- Scope an evidence system, not a signature widget. The signature is one of six recorded elements. The other five, plus retrieval and print, are the work.
- Budget the failure path. The three-attempt lockout and paper fallback are required, so they belong in the first release.
- Settle the storage question before design. Three requirements change owner depending on who is system of record. Decide it, and tell your customer which of you holds it.
- Treat signed-state as an integration contract. The transmission gate spans two systems and needs to be verifiable, not merely notified.
- Retention outlives your release cycle. These forms are kept three years from the return due date or IRS received date, whichever is later, and may be retained electronically per Revenue Procedure 97-22.
- Get advice for your own role. Which requirements attach to you depends on the IRS roles your company holds and how your workflow is arranged.
Frequently asked questions
Does supporting Form 8879 electronic signatures make my platform responsible for the accountant's compliance? No. Publication 1345 allocates requirements by role. Software developer requirements attach to the software; the ERO's duties, including confirming the taxpayer's identity, stay with the firm. Your job is to enable the ERO to meet theirs, including producing the recorded information on request.
Is knowledge-based authentication required, or one option among several? Publication 1345 states the software "will enable the identity verification using knowledge-based authentication questions" for these forms, and requires recording passed KBA results. Whether KBA alone satisfies the publication's separate reference to a NIST assurance level is genuinely open, and not a question to settle from a vendor's feature list.
What do we record for "taxpayer's login identification, username" if signers have no accounts? The published sources do not answer this. Record a durable unique session identifier, document the choice, and be able to explain it. Do not present something as an account username if it is not one.
Do these requirements apply if taxpayers upload a signed PDF instead of signing in the product? Publication 1345 excludes handwritten signatures delivered by hand, mail, private delivery service, fax, email or a website from the remote-transaction definition. Retention and the ERO's identity duties still apply to the form itself.
Where Verdocs fits
Verdocs is embedded signing infrastructure for vertical SaaS platforms, so the audit trail, identity step, sealed record and branded signer experience are ours to build and yours to control. For KBA, we orchestrate the step through a third-party identity provider working from public records rather than holding an identity dataset ourselves. Embedding eSignature in accounting practice software covers the same workflow from the platform side, including season volume and per-firm branding.
We will not tell you that embedding our platform makes your product compliant with Publication 1345, because that depends on roles and workflow that are yours. We will be specific in writing, before you build, about which requirements our platform addresses and which sit with you or your customer. If you are scoping this work, start a conversation or read 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. Electronic Signature Guidance for Forms 8878 and 8879, Digital Identity Verification Requirements, Electronic Signature Via Remote Transaction, Identity Verification, Identity Verification Failure and Electronic Records: pages 15 to 17. Additional Requirements for Software Developers Enabling Electronic Signatures for Forms 8878 and 8879: pages 29 to 30. Intermediate Service Providers Participating as Resellers: page 28.
- Form 8879, IRS e-file Signature Authorization, Rev. 01-2021, Catalog Number 32778X. Important Notes for EROs and the transmission caution: page 2.
- Form 8878, IRS e-file Authorization for Form 4868 or Form 2350, 2025, Catalog Number 32777M. Important Notes for EROs: page 2.
- Revenue Procedure 97-22, Internal Revenue Bulletin 1997-13, cited by both forms for electronic retention.
- NIST Special Publication 800-63-4, Digital Identity Guidelines, Revision 4, July 2025, superseding SP 800-63-3.
- NIST Special Publication 800-63-2, Electronic Authentication Guideline, August 2013, withdrawn 22 June 2017. The document whose title Publication 1345 still cites.
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.
