Digital Signature Standard: What FIPS 186-5 Covers

Key Takeaways

• It is a NIST algorithm specification, not a signing product. FIPS 186-5 tells software which maths to use and says nothing about whether your contract holds up.
• Three algorithms are approved: RSA, ECDSA and EdDSA. The original DSA that gave the standard its name can now only verify old signatures.
• Enforceability comes from eIDAS and the ESIGN Act. Neither names an algorithm, so "FIPS compliant" answers a different question.
• Every algorithm in it is breakable by a large quantum computer. NIST published replacements in 2024 and wants the vulnerable ones gone by 2035.

If a vendor says their e-signature product meets the Digital Signature Standard, the claim is probably true and probably irrelevant to your decision. The standard is a procurement rule for US federal cryptography. Your contract lives or dies on identity evidence instead.

What is the Digital Signature Standard?

The Digital Signature Standard, published by NIST as FIPS 186-5, specifies the algorithms that US federal systems may use to generate and verify digital signatures. The current revision took effect on 3 February 2023 and replaced FIPS 186-4 from 2013, which was withdrawn a year later. You can read the scope on NIST's own listing for the current revision.

Its purpose is narrow. It describes key generation, signing and verification for a short list of asymmetric algorithms, and fixes the parameters those algorithms may use. Three properties follow from the maths: a recipient can tell the data was not modified after signing, can tell which key signed it, and can show the signature to a third party as evidence.

Worth knowing: NIST added a planning note in May 2025 saying issues were found that will be corrected in a future revision. A standard being current does not mean it is finished.

The name is a historical accident. The first FIPS 186 in 1994 specified one algorithm, DSA, designed at the NSA, in roughly two pages. Industry had already deployed RSA and largely ignored DSA. Thirty years on, the standard still carries DSA's name while no longer letting anyone sign with it.

Which algorithms does FIPS 186-5 approve?

Three signature algorithm families are approved for new signatures, and the oldest one has been demoted to verification duty.

Two of those changes matter beyond compliance paperwork. Deterministic ECDSA removes the per-signature random number that has broken real implementations when the randomness was weak or reused. And because the ANSI X9.62 standard that carried the ECDSA details was withdrawn, NIST wrote those details back into FIPS 186-5 itself.

What is absent is as useful to know. The standard does not cover the elliptic curves themselves, which sit in a separate NIST publication, nor the format of a signed PDF, the identity checks before signing, or retention of the file afterwards. Those are the parts buyers care about.

How does a cryptographic standard differ from signature law?

A cryptographic standard constrains the algorithm. Signature law constrains the evidence. They are separate systems that intersect only loosely, which is where most buyer confusion starts.

The confusion is old. A Security Stack Exchange question on the difference between an electronic signature and a digital signature has drawn three answers and steady votes since 2012, and its accepted answer draws the line cleanly: an electronic signature is any mechanism for identifying an author in an electronic system, and a digital signature is the cryptographic subtype where a private key signs a hash of the document.

What does eIDAS require in the EU?

eIDAS sets three tiers and attaches different legal weight to each. A plain electronic signature cannot be denied legal effect purely for being electronic or for not being qualified. An advanced electronic signature must meet four conditions under Article 26: uniquely linked to the signatory, capable of identifying them, created with data they keep under sole control with a high level of confidence, and linked to the signed data so later changes are detectable. A qualified electronic signature adds a qualified certificate and a certified creation device, and only that tier is automatically equivalent to a handwritten signature across the Union. The consolidated regulation text carries the operative wording.

Notice what is missing from Article 26. No curve, no key length, no padding scheme. A signature built on a FIPS-approved algorithm can fail it if the signer never controlled the key, and one built on something NIST never evaluated can satisfy it.

The 2024 amendment, Regulation (EU) 2024/1183, moves the tiers closer to ordinary users: once onboarded to a European Digital Identity Wallet, a person can sign with a qualified electronic signature free of charge for non-professional purposes. The Commission's trust-services questions and answers tracks the changes.

What does the ESIGN Act require in the US?

Less than most people assume. The ESIGN Act of 2000 defines an electronic signature as an electronic sound, symbol or process attached to or logically associated with a record and adopted by a person with intent to sign, and provides that a signature or contract cannot be denied legal effect, validity or enforceability solely because it is electronic. The act as enacted is short and worth skimming once.

A typed name in an email satisfies that definition. A dispute turns on whether you can show who signed, when, and that the file has not changed since. That is an evidence problem, and cryptography is one of several ways to solve it.

What actually breaks in everyday signing workflows?

Not the algorithm. The trust decisions wrapped around it.

A Security Stack Exchange question asking what happens when you validate a digital signature collected 19 votes and a blunt accepted answer at 34. The questioner had followed an official government instruction sheet for checking a signed PDF, which told the reader to import the certificate from the document into the local trust store and mark it a trusted root. The answer's objection: that produces a green checkmark rather than security, because no trust chain is involved, revocation stops being checked, and every future certificate from that issuer becomes trusted.

That failure has nothing to do with RSA or ECDSA. It is a verification workflow asking a non-expert to manufacture the trust the signature was supposed to prove. The same problem recurs in three other places:

• Signatures that validate only on the signer's machine. Trust imported locally does not travel with the file, so the counterparty still sees a warning.
• Image signatures pasted into a PDF. A scanned squiggle is an electronic signature under ESIGN and carries no tamper evidence. Our walkthrough of how to sign a PDF or Word file properly covers the difference.
• A signed file with no surrounding record. The hash proves the document is unchanged. It does not prove the person who typed the name is the person you contracted with.

How should you evaluate a signing tool against the standard?

Work from the dispute backwards. Four questions separate real requirements from vendor vocabulary.

1. Do you need a qualified signature at all?

Most commercial agreements do not. A qualified electronic signature requires a qualified trust service provider, a qualified certificate and a certified creation device, and it exists for the narrow set of cases where national law demands equivalence with a wet-ink signature. Notarial deeds and certain property transactions fall there. A statement of work does not. If your legal team has not named a statute, you are shopping in the advanced or simple tier, and our breakdown of what the signature tiers change in practice reads faster than the regulation.

2. What does the tool hash, and what does it keep?

Ask for the hash function, the moment the hash is taken, and the exact fields stored alongside it. A SHA-256 hash of the final PDF plus a timestamp, a verified email address, an IP address and the browser string is a defensible record. A hash with no identity evidence attached is a tamper check and nothing more. A date field typed by the signer is neither, which is why the date beside a signature is weaker evidence than the system timestamp next to it.

3. Where do the signed file and the audit record live?

For any EU-facing contract this is the question with teeth, and it is a data protection question rather than a cryptographic one. Ask which country the signed PDFs sit in, which entity controls the storage, and whether the audit log leaves that jurisdiction. meetergo's data privacy law overview and security posture set out how we answer it, and the same questions are worth putting to any vendor you shortlist.

4. Does the post-quantum timeline touch your retention period?

Only if you keep signed documents for a long time. Every algorithm in FIPS 186-5 is vulnerable to a sufficiently large quantum computer, a point NIST makes in its own briefings. Two replacements arrived in August 2024: FIPS 204, the lattice-based ML-DSA from CRYSTALS-Dilithium, and FIPS 205, the hash-based SLH-DSA from SPHINCS+. NIST's post-quantum project page sets out the plan to remove quantum-vulnerable algorithms from its standards by 2035.

For a three-year service agreement, none of this changes your shortlist. For a 30-year deed or an archive with statutory retention, ask the vendor for their migration plan and write the answer down.

Pro tip: A vendor who answers "we use FIPS 186-5 approved algorithms" to question 2 or question 3 has changed the subject. The algorithm is table stakes. The evidence and the jurisdiction are the product.

Where does meetergo fit, and where does it not?

meetergo is a scheduling and revenue-pipeline tool that runs the path from a booking to a signed contract, with e-signatures built into the booking flow rather than bolted on as a separate subscription. The honest framing for buyers reading this article: it is engineered around the audit record rather than around certificate-based signing.

Here is what the product does, as mechanics rather than badges. Before signing, the recipient confirms their email address with a six-digit one-time code, valid ten minutes with a five-attempt lockout, producing a confirmed identity record tied to the document. Every signed PDF is hashed with SHA-256 and the hash stored per submission, so a later modification stops matching. The audit record holds the timestamp, verified email address, IP address, browser and document hash. Signature data and signed PDFs sit on EU servers in Germany. Fillable PDFs are signed in their own fields, templates auto-fill from booking answers through routing forms, and signing also works inside a meetergo connect video call.

Now the limits, because the claim matters more than the pitch. meetergo calls its flow a Fortified Electronic Signature. That is a product name, not a tier defined anywhere in eIDAS, and not an eIDAS certification. meetergo is not a qualified trust service provider, issues no qualified certificates, and claims no FIPS-validated cryptographic module or NIST conformance. By its own description the signature drops to the simple tier if email verification is switched off, and that verification is gated to the Suite plan and above. If your counsel has written "qualified electronic signature" into a requirement, meetergo is not the answer.

Paid tiers run a 7-day trial, the Free plan never expires, and no tier charges a per-document or per-signature fee. Details sit on the pricing page.

What mistakes do buyers make with this standard?

• Treating FIPS 186-5 as a compliance badge. It constrains algorithms in US federal systems. Quoting it in a questionnaire for a commercial contract tool answers a question nobody asked.
• Assuming a stronger algorithm makes a stronger signature. Article 26 turns on sole control of the signing key and detectability of later changes. Key length is not in the test.
• Buying the qualified tier by default. It costs more and adds identity-proofing friction for every signer. Over-specifying it kills completion rates.
• Ignoring where the audit record is stored. A perfect hash held in a jurisdiction your data protection officer has not approved is a compliance problem in a cryptography costume. Our notes on choosing GDPR-ready software cover what to ask.
• Letting signers paste an image of their signature. Legally a signature in most jurisdictions, evidentially close to worthless. If you still send Word files out, our free contract templates beat a scanned squiggle.

Send your next contract with an audit trail attached

The algorithm question is settled for almost everyone reading this. What is usually unsettled is whether the signature arrives attached to a verified identity, a timestamp and a file nobody can quietly edit afterwards. You can test that this week.

Start on the Free plan, send one real contract through a booking flow, and look at what lands in the audit record. Start signing contracts on meetergo's free plan, no credit card required. Teams that want to wire the signed-document event into their own systems can do it through the meetergo API.

100% GDPR compliant

Booking + video conferencing in one tool.

No downloads.No extra costs.Set up in 30 seconds.

Use for free

Sarah NowakManaging Director · Intro call · 30 min09:0010:3014:00

100% GDPR compliant

Booking + video conferencing in one tool.

No downloads.No extra costs.Set up in 30 seconds.

Use for free

Frequently Asked Questions

Is the Digital Signature Standard the same thing as an e-signature law?

No. FIPS 186-5 specifies signature algorithms for US federal systems. eIDAS in the EU and the ESIGN Act in the US decide what legal effect a signature carries. A tool can follow the NIST algorithms and still produce thin evidence, or produce strong evidence using algorithms NIST never evaluated.

Can I still use DSA?

Only to verify signatures created before the 2024 transition deadline. FIPS 186-5 removed DSA from signature generation, partly because of continuing progress in discrete logarithm algorithms. New signatures use RSA, ECDSA or EdDSA.

Does meetergo offer a qualified electronic signature?

No. Its flow uses email one-time-code verification, SHA-256 hashing of the signed PDF and a stored audit record, and the company is not a qualified trust service provider. Where a statute demands a qualified signature, you need a provider on the EU trusted list for that document.

What is the difference between FIPS 186-5 and FIPS 204?

FIPS 186-5 covers the classical algorithms in use today, all of which a large quantum computer could break. FIPS 204 specifies ML-DSA, a lattice-based algorithm published in August 2024 as a post-quantum replacement. FIPS 205 specifies a hash-based alternative, SLH-DSA.