HMAC vs Digital Signatures: Which One Do You Actually Need?

Both HMAC and digital signatures answer the same basic question: did this message arrive unmodified, and was it really sent by who claims to have sent it? They get to that answer in fundamentally different ways, with very different operational properties. Choosing the wrong one is a common source of broken security designs and unnecessary complexity.

The Fundamental Difference

HMAC uses a single shared secret. Both the sender and the verifier hold the same key. Anyone with the key can create a valid HMAC; anyone with the key can verify one. There's no asymmetry — the verifier and the forger are the same role.

A digital signature uses a key pair. The signer holds a private key; verifiers hold the corresponding public key. Only the private key holder can produce a valid signature, but anyone with the public key can verify it. This asymmetry is the whole point.

Both prove integrity (the message wasn't modified) and authenticity (it came from someone with the right key). But signatures additionally provide non-repudiation— the signer can't plausibly deny producing the signature, because nobody else had the private key. HMAC has no such guarantee: the verifier could have forged it themselves.

What HMAC Is Good For

HMAC's strengths are speed and simplicity. It's a thin wrapper over a hash function — computing an HMAC-SHA-256 is essentially two SHA-256 evaluations. Verification is the same operation, recompute and compare. There's no large-integer arithmetic, no elliptic curves, no certificate machinery. A microcontroller can do it.

Use HMAC when:

• Both parties trust each other. The shared-secret model is fine when sender and verifier are the same organisation, or have a pre-existing trust relationship sealed by some other mechanism.
• The number of parties is small. One sender, one verifier — or a handful of each. Distributing a shared secret to ten thousand verifiers is impractical.
• Performance matters. HMAC is roughly 1000× faster than RSA-2048 signing and 10-100× faster than Ed25519 signing for typical message sizes.
• You don't need non-repudiation. If the verifier finding a valid HMAC is sufficient — you don't need to prove to a third party that the sender sent it — HMAC is enough.

Concrete examples: API request signing (AWS SigV4 uses HMAC-SHA-256), webhook signatures (Stripe, GitHub, Slack all use HMAC), session cookies, JWT tokens with HS256, message integrity inside TLS records.

What Digital Signatures Are Good For

Signatures shine wherever you have many verifiers, untrusted distribution channels, or a need for legal/audit non-repudiation. The asymmetry means you can publish your public key on a billboard and the world can verify your signatures without you ever sharing a secret.

Use digital signatures when:

• One signer, many verifiers. Software updates signed by Apple and verified by every iPhone. TLS certificates signed by a CA and verified by every browser.
• You need third-party verification. Code signing, document signing, blockchain transactions — situations where someone other than the original recipient may need to verify authenticity later.
• You can't share secrets. A user signing a transaction on a hardware wallet wants to prove ownership without ever revealing the private key, even to the verifier.
• Auditability is required. Regulated environments where "we both have the key" isn't a sufficient audit trail.

Concrete examples: TLS certificates, SSH host keys, package signing (apt, npm provenance, sigstore), code signing (Authenticode, Apple), blockchain transactions, JWT tokens with RS256 or ES256.

Where Engineers Pick Wrong

The most common mistake: using digital signatures where HMAC would do. A team builds an internal API where one service authenticates another. They reach for RSA signatures because "signed" sounds more secure than "keyed." Now they have a key-management problem (rotating private keys, distributing public keys), CPU overhead on every request, and no real benefit — both services trust the same operator anyway.

The opposite mistake: using HMAC where signatures are required. A vendor publishes a webhook signature scheme using HMAC, then later wants third-party tools to verify webhooks. They can't — sharing the HMAC secret with every third-party tool means any of those tools could forge events. The fix is moving to signatures (or, less elegantly, having the third-party tool proxy through the original recipient).

A Quick Decision Tree

• One sender, one verifier, both you? → HMAC
• One sender, many independent verifiers? → Digital signature
• Verifier needs to convince a third party later? → Digital signature
• Performance-critical, both ends trusted? → HMAC
• Embedded device verifying upstream messages? → HMAC (signatures are heavy on tiny CPUs)
• Software update, document signing, certificate? → Digital signature

The Honest Summary

HMAC is a hammer; signatures are a torque wrench. HMAC is faster, simpler, and the right tool when you control both ends. Signatures cost more compute and key management overhead but unlock a different set of properties — public verification, non-repudiation, large-scale distribution. Pick based on whether you need those properties, not based on which one sounds more impressive.