Digital Signatures Guide: How Signing Works and Where It Protects You

A digital signature is a value computed with a private key over a piece of data, which anyone holding the matching public key can check to prove who signed the data and that it has not changed since. It is the electronic equivalent of a tamper-evident seal plus a signature, and it underpins software updates, TLS certificates, access tokens and signed documents. Signatures give integrity, origin authentication and, in the right legal setting, non-repudiation; they do not give confidentiality. This guide explains how signing works in plain terms, then covers the algorithms in current NIST standards, the main places signatures are used, and the mistakes that let attackers forge or abuse them. It is written for engineers, identity teams and security architects, and links to deeper guides on code signing, JWTs and PKI rather than repeating them.

Key takeaways

• Hash, then sign. The signer hashes the data and applies the private key to the digest; the verifier recomputes the hash and checks it with the public key.
• Use modern schemes. RSA-PSS, ECDSA and EdDSA are in FIPS 186-5; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are the post-quantum replacements.
• A valid signature is not the same as a trusted one. Verifiers must also check which key, which issuer and which algorithm, as the Storm-0558 forgeries showed.
• The signing key is a high-value non-human identity. Whoever holds it can impersonate your software, your token issuer or your organisation; keep it in an HSM or managed signing service.
• Plan for revocation before you need it. Leaked keys baked into firmware or trusted for driver signing can stay usable for years.

What it is

Think of a wax seal that only you can make, but that anyone can recognise. The private key makes the seal; the public key lets others recognise it. If one bit of the sealed data changes, the check fails.

A digital signature provides three properties:

• Integrity: the data has not been modified since it was signed.
• Origin authentication: it was signed by the holder of a specific private key.
• Non-repudiation: the signer cannot easily deny signing, provided the key was under their sole control. This is a legal and procedural property as much as a technical one.

Signatures differ from message authentication codes (MACs) such as HMAC. A MAC uses one shared secret key, so any party able to verify can also create a valid tag, and it cannot prove which party produced it. The difference matters in JWTs, where HS256 is a MAC and RS256, PS256, ES256 and EdDSA are signatures. For the shared-key versus key-pair distinction in general, see the Symmetric vs Asymmetric Encryption Guide.

How it works

1. Key generation: the signer creates a key pair, ideally inside an HSM or KMS so the private key never exists in plaintext outside it.
2. Binding the public key to a name: a certificate authority issues an X.509 certificate, or the key is published in a JWK Set, or pinned in a trust store. See the PKI Basics Guide.
3. Hashing: the data is reduced to a fixed-length digest with a hash such as SHA-256 or SHA-384. Signing the digest is efficient and means the hash's collision resistance becomes part of the signature's security. See the Hashing Guide.
4. Signing: the private key is applied to the digest with the chosen scheme, producing the signature, which is attached to or stored alongside the data.
5. Verification: the verifier recomputes the digest, checks the signature with the public key, and then checks trust: is this key allowed to sign this kind of object, for this issuer, at this time, and has it been revoked?

Step 5 is where most real-world failures happen. The cryptographic check is usually correct; the trust decision around it is not.

Signature algorithms compared

FIPS 186-5 (February 2023) superseded FIPS 186-4 and no longer approves DSA for generating new signatures. NIST SP 800-131A Rev. 2 disallows RSA signature generation below 2048 bits, elliptic curve keys below 224 bits, and SHA-1 for signature generation. The NIST IR 8547 initial public draft (November 2024) proposes deprecating 112-bit RSA and ECDSA after 2030 and disallowing quantum-vulnerable signatures after 2035; it is still a draft. Migration planning is covered in the Post-Quantum Cryptography Migration Guide.

Why it matters

Signatures are where trust in machines and software is decided, usually without a human in the loop.

• JWT signatures: RFC 7515 defines the signing input as the base64url header and payload joined by a full stop, so both are protected. RFC 7518 registers none, meaning no signature at all. RFC 8725 (JWT Best Current Practices) requires libraries to let the caller fix an allow-list of algorithms and bind each key to one algorithm, which defeats both alg: none acceptance and the RS256 to HS256 confusion where an RSA public key is misused as an HMAC secret. Never take the algorithm from the token itself. See the JWT Security Guide.
• Code signing: a signature proves which key signed a binary, not that the binary is safe. Timestamping lets a signature stay valid after the certificate expires, which is useful and also why stolen expired certificates remain dangerous. See the Code Signing Security Guide.
• Keyless signing: projects such as Sigstore issue short-lived signing certificates tied to an OIDC identity and record signatures in a public transparency log, which removes the long-lived key from developer machines.
• Legal signatures in the EU: eIDAS (Regulation (EU) No 910/2014, amended by Regulation (EU) 2024/1183) defines an advanced electronic signature as one uniquely linked to and capable of identifying the signer, created with data under the signer's sole control and linked to the data so that changes are detectable (Article 26). A qualified electronic signature is an advanced signature created by a qualified signature creation device and based on a qualified certificate; under Article 25(2) it "shall have the equivalent legal effect of a handwritten signature".

Where identity fits: signing keys are non-human identities

A signing key is a credential that speaks for an organisation with no human involved at verification time. Treat it like the most privileged service account you have.

• Custody: generate signing keys in an HSM or cloud KMS as non-exportable, and expose signing only through a service with authentication, approval for release keys, and per-request logging. ATT&CK tracks theft of key files as T1552.004 Private Keys.
• Ownership and offboarding: every signing key needs a named owner, a defined lifetime and a rotation process triggered when people leave. In the Coupang breach, a former engineer kept a token signing key with a reported 5 to 10 year validity and used it to forge tokens after leaving.
• Scope: one key per purpose and per product, so a leak has a bounded blast radius.

See the Machine Identity, PKI and Certificate Lifecycle Guide and the Cryptographic Key Management Guide.

Common misconceptions

• "Signed means safe." A signature only identifies the signer. After Lapsus$ leaked two NVIDIA code signing certificates, malware signed with them appeared within about a day, and Windows still accepted the expired certificates for driver signing. Pair signature checks with allow-listing policy such as Windows Defender Application Control (ATT&CK T1553.002 Code Signing).
• "If the signature verifies, the token is valid." In the Microsoft Storm-0558 key breach, a consumer signing key that should have been retired was used to forge tokens that Exchange Online accepted for enterprise accounts, because issuer and key scope were not validated. ATT&CK covers this as T1606 Forge Web Credentials.
• "Signing encrypts the data." It does not. A signed JWT or document is readable by anyone; encrypt separately if the content is confidential.
• "A leaked key can just be revoked." Revocation depends on verifiers checking it. In the MSI signing keys leak, firmware signing keys for 57 products and Intel Boot Guard keys for 116 products were exposed, and keys built into hardware trust chains are hard to replace on devices already in the field.
• "ECDSA and EdDSA are interchangeable." ECDSA depends on a fresh, unbiased random nonce for every signature; EdDSA derives it deterministically. Weak randomness in ECDSA signing can leak the private key.
• "Any electronic signature is legally equal to a handwritten one." Under eIDAS, only qualified electronic signatures carry that equivalence automatically; others cannot be denied effect solely for being electronic, but their weight is assessed case by case.

Related concepts

• Hash functions and MACs: the digest a signature covers, and the shared-key alternative. See the Hashing Guide.
• Certificates and PKI: how a public key is bound to a name and revoked. See the PKI Basics Guide and the Certificate Transparency Guide.
• Timestamping: a trusted time authority countersigns a signature so it can be validated after the signing certificate expires.
• Crypto-agility: the ability to swap signature algorithms, which post-quantum migration will test. See the Crypto-Agility Guide.

Rolling out signing controls

1. Inventory signing keys: code signing certificates, token issuers, SAML signing certificates, GPG and SSH signing keys, firmware keys; record owner, algorithm, location and expiry.
2. Move keys into hardware: migrate to HSM or KMS backed signing; for code signing, sign in the build pipeline through a signing service, never on laptops.
3. Fix verifiers: pin algorithms, validate issuer to key binding and audience for tokens, and enforce revocation checks. Test in a staging tenant with deliberately bad tokens (alg: none, wrong issuer key) before production.
4. Rotate: introduce a new key alongside the old one (publish both in the JWK Set or trust store), switch signing, then retire the old key once no valid artefacts depend on it. Rollback means re-enabling the old key for verification only.
5. Monitor: log every signing operation and verification failure.

Detection and measurement

• Signals: signing requests outside the release pipeline or business hours, unusual signing volume, tokens with no matching login event, verification failures spiking after a change, and new keys appearing in JWK Sets.
• Metrics: percentage of signing keys in HSM or KMS; percentage with a named owner and expiry; mean time to rotate a signing key on demand; number of verifiers without an algorithm allow-list; count of RSA keys below 2048 bits or SHA-1 signatures still issued.

Framework mapping

Practitioner checklist

• Keep an inventory of every signing key and certificate with owner, purpose, algorithm, location and expiry.
• Generate and hold signing keys as non-exportable in an HSM or KMS; sign through a controlled service with approvals for release keys.
• Use RSA-PSS (3072 bits or more for new keys), ECDSA P-256 or Ed25519 today; plan ML-DSA or SLH-DSA for long-lived trust anchors.
• Pin accepted algorithms in every verifier, reject alg: none, and bind each key to one algorithm and one issuer.
• Timestamp code signatures and enforce revocation checking; pair signature checks with allow-listing policy.
• Rotate signing keys on a schedule and when anyone with access leaves.
• Log every signing operation and alert on signing outside approved pipelines.
• Test verifiers with malformed and forged signatures as part of release testing.

Standards and references

• NIST: FIPS 186-5, Digital Signature Standard (DSS)
• NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard
• NIST: FIPS 205, Stateless Hash-Based Digital Signature Standard
• IETF: RFC 8032, Edwards-Curve Digital Signature Algorithm (EdDSA)
• IETF: RFC 8017, PKCS #1: RSA Cryptography Specifications Version 2.2
• IETF: RFC 7515, JSON Web Signature (JWS)
• IETF: RFC 8725, JSON Web Token Best Current Practices
• EUR-Lex: Regulation (EU) No 910/2014 (eIDAS)

Related NHI Mgmt Group resources: Code Signing Security Guide · JWT Security Guide · PKI Basics Guide · Symmetric vs Asymmetric Encryption Guide · Storm-0558 and Cloud Key Theft Profile