A message that is not authenticated can be forged or altered in transit, and the receiver has no way to tell. MITRE D3FEND names the countermeasure Message Authentication (D3-MAN) and defines it as "Authenticating the sender of a message and ensuring message integrity." It sits under the Harden tactic as a child of Message Hardening (D3-MH), next to Message Encryption (D3-MENCR) and Transfer Agent Authentication (D3-TAAN), and has one child of its own, Bus Message Authentication (D3-BMA). This card explains the two mechanisms D3FEND describes, digital signatures and message authentication codes, where each is implemented in email, APIs, webhooks and tokens, how to verify that receivers actually check them, and where the control fails. It is for application security engineers, platform teams and anyone who owns signing keys or shared secrets.
Key takeaways
- Two mechanisms, different properties. Digital signatures use a private key and give non-repudiation; message authentication codes (MACs) use a shared symmetric key and are cheaper, but anyone who can verify can also forge.
- D3FEND maps no ATT&CK techniques to it. As of D3FEND 1.6.0 the technique page states there are no related offensive techniques in this release, so the value must be argued from the definition and the Digital Message artefact.
- Verification is the control, not signing. A signed message protects nothing if the receiver skips the check, accepts any algorithm, or compares MACs with a non-constant-time equality.
- Signatures cover less than people assume. S/MIME signs the MIME body unless the sender wraps headers, and HTTP Message Signatures sign only the components the signer lists.
- The key is a non-human credential. HMAC secrets and signing keys need inventory, ownership, rotation and storage in a secrets manager, like any other machine credential.
D3-MAN at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-MAN (d3f:MessageAuthentication) |
| Tactic | Harden |
| Parent technique | Message Hardening (D3-MH) |
| Siblings and child | Message Encryption (D3-MENCR), Transfer Agent Authentication (D3-TAAN); child Bus Message Authentication (D3-BMA) |
| Digital artefact | authenticates Digital Message |
| Mechanisms named by D3FEND | Digital signature (S/MIME given as the email example); Message Authentication Code |
| D3FEND considerations | Public keys verified by a certification authority; signatures give non-repudiation; symmetric keys exchanged over a private channel and managed per pair of participants |
| ATT&CK techniques related in D3FEND | None in D3FEND 1.6.0 (checked November 2026) |
How it works
Digital signatures
D3FEND describes the S/MIME pattern: the sender hashes the message and signs the hash with a private key; the receiver uses the sender's public key to check the signature against a hash it computes itself, and any difference means the message did not come from that sender or was altered in transit. RFC 8551 (S/MIME 4.0, Standards Track, April 2019, obsoleting RFC 5751) requires sending agents to use the SignedData content type, with either application/pkcs7-mime or multipart/signed. Receiving agents must support ECDSA with P-256 and SHA-256, EdDSA with curve25519 and RSA PKCS #1 v1.5 with SHA-256.
Message authentication codes
A MAC is a short tag computed from the message and a secret key shared by sender and receiver. The receiver recomputes the tag and compares. HMAC, specified in NIST FIPS 198-1, builds a MAC from an approved hash function and a shared secret key. NIST published a plan in June 2025 to withdraw FIPS 198-1 and move its content to SP 800-224, so check the current publication when citing it.
Choosing between them
| Question | Digital signature | MAC (for example HMAC-SHA256) |
|---|---|---|
| Who can verify | Anyone with the public key | Only holders of the shared secret |
| Who can forge | Only the private key holder | Any holder of the shared secret, including every verifier |
| Non-repudiation | Yes, when the public key is bound to an identity by a CA | No |
| Key distribution | Publish public keys or certificates | Secure exchange per sender and receiver pair |
| Cost | Higher CPU per message | Low; suits high-volume and constrained systems |
| Fits when | Many receivers, third-party verification, audit evidence | One sender and one receiver under common control, webhooks, internal service calls |
Where it is implemented
| Message type | Standard or feature | Mechanism | What the verifier must check |
|---|---|---|---|
| Email between people | S/MIME (RFC 8551); OpenPGP | Signature | Signature valid, signer certificate chains to a trusted CA and matches the From address |
| Email between domains | DKIM (RFC 6376), which D3FEND files under Transfer Agent Authentication | Signature by the signing domain | Signature valid and the signing domain aligned with the visible From domain (DMARC) |
| HTTP requests and responses | HTTP Message Signatures (RFC 9421, Standards Track, February 2024) | Signature or MAC; algorithms include hmac-sha256, rsa-pss-sha512, ecdsa-p256-sha256 and ed25519 | Required components are covered (for example @method, @target-uri), created or expires is within policy, key ID maps to an expected key |
| Cloud API calls | Provider request signing, for example AWS Signature Version 4 | Keyed hash over a canonical request; SigV4a uses ECDSA | Done by the provider; AWS denies most requests that arrive more than five minutes after their timestamp |
| Webhooks | Provider HMAC headers, for example GitHub's X-Hub-Signature-256 (HMAC-SHA256, value prefixed sha256=) | MAC with the webhook secret | Recompute over the raw body and compare in constant time |
| Tokens | JWS and JWT (RFC 7515, RFC 7519, BCP 225 RFC 8725) | Signature or MAC | Algorithm from an allow list, every cryptographic operation validated, aud checked |
| Vehicle and industrial buses | See D3-BMA Bus Message Authentication | Usually truncated MACs | Freshness counters and key management per bus |
Email domain authentication is covered in the DMARC, SPF and DKIM Guide and user-level signing in the OpenPGP and S/MIME Email Encryption Guide.
Where identity fits
Every MAC secret and signing key is a non-human credential. Webhook secrets sit in application configuration, HMAC keys are shared between services, and signing keys for tokens or API requests often outlive the people who created them. A leaked MAC key lets the holder forge messages that pass every check. Treat these keys like any other machine credential: one owner, one purpose, stored in a secrets manager, rotated on a schedule and on suspected exposure. See the Webhook Secrets Security Guide and the JWT Security Guide.
Implementation steps
- Inventory message flows. List inbound webhooks, service-to-service calls, signed tokens, signed emails and message queues, with who signs, who verifies and which key is used.
- Pick the mechanism per flow. Use the decision table above: MAC for single-pair, high-volume flows under common control; signatures where several parties verify or where evidence of origin matters.
- Define what is covered. For HTTP signatures, list required components (method, target URI, content digest, date). For S/MIME, decide whether header protection through a message/rfc822 wrapper is needed. Anything not covered can be changed without breaking the signature.
- Add freshness. Include a timestamp or nonce and reject messages outside a window. RFC 9421 defines
created,expiresandnonceparameters for this purpose. - Verify strictly. Pin the expected algorithm per key, reject missing signatures rather than treating them as optional, verify over the raw received bytes, and compare MACs in constant time as GitHub's documentation requires.
- Manage keys. Store keys in a secrets manager or HSM, support two active keys during rotation (key IDs make this possible), and record each key's owner and expiry.
- Roll out in report-only mode. Log verification failures without rejecting for a pilot period, fix senders, then enforce. Keep the ability to switch a single flow back to report-only if a sender breaks.
How to verify it works
- Negative tests per flow: send a message with no signature, a wrong signature, a tampered body, an expired timestamp and a disallowed algorithm. Every one must be rejected and logged.
- Replay test: resend a valid captured message after the freshness window. It must be rejected.
- Key rotation drill: rotate a key in staging and confirm both old and new keys verify during the overlap and the old key fails after it.
- Code review checks: search for plain equality comparison of MACs, verification disabled by configuration flags, and token libraries called without an algorithm allow list.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Inbound flows with enforced verification | 100% of external webhooks and service calls | Coverage |
| Flows passing the negative test set | 100% | Proves verification is real |
| Signing and MAC keys with a named owner and expiry | 100% | Keys are credentials that need lifecycle management |
| Keys older than the rotation policy | Zero | Limits the damage of an undetected leak |
| Verification failures investigated | All failures from known senders | Failures signal forgery attempts or broken senders |
Limits, bypasses and failure patterns
- Optional verification: receivers that accept unsigned messages "for compatibility" give an attacker a downgrade path. Reject unsigned messages once senders are migrated.
- Algorithm confusion: RFC 8725 requires libraries to let callers specify the allowed algorithms and says the "none" algorithm should only be used when the token is protected by other means. Accepting the algorithm named in the message lets an attacker choose a weaker one.
- Partial coverage: headers outside an S/MIME signature, or HTTP components not listed in Signature-Input, can be altered without detection.
- Replay: a valid signature stays valid. Without a timestamp, nonce or sequence number, a captured message can be sent again.
- Shared secret sprawl: one HMAC key reused across many senders means any one of them can impersonate the rest, and a leak from the weakest system forges for all.
- Timing leaks and legacy hashes: non-constant-time comparison and legacy SHA-1 headers (GitHub keeps X-Hub-Signature only for legacy purposes) weaken an otherwise sound design.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 Transmission Confidentiality and Integrity, SC-8(1) Cryptographic Protection | Integrity of transmitted information |
| NIST SP 800-53 Rev 5 | SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection | Key lifecycle and approved algorithms |
| NIST SP 800-53 Rev 5 | AU-10 Non-repudiation | Where digital signatures provide evidence of origin |
| NIST CSF 2.0 | PR.DS-02 | Data in transit protected |
| MITRE D3FEND | D3-MH, D3-MAN, D3-BMA | Parent, technique and child |
The sibling for mail servers is D3-TAAN Transfer Agent Authentication. The wider framework is in the MITRE D3FEND Guide.
Practitioner checklist
- Inventory every signed or MAC-protected message flow with signer, verifier and key.
- Choose signature or MAC per flow using who must verify and whether non-repudiation is needed.
- Define covered components and add a timestamp or nonce to every flow.
- Pin algorithms per key and reject unsigned or unexpected-algorithm messages.
- Compare MACs in constant time over the raw received bytes.
- Store keys in a secrets manager or HSM with an owner and expiry.
- Use one key per sender and purpose; never share a MAC key across many senders.
- Run negative, replay and rotation tests before enforcing and after changes.
Standards and references
- MITRE D3FEND: Message Authentication (D3-MAN)
- NIST: FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC)
- IETF: RFC 8551 S/MIME Version 4.0 Message Specification
- IETF: RFC 9421 HTTP Message Signatures
- IETF: RFC 8725 JSON Web Token Best Current Practices
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-8, SC-12, SC-13)
- GitHub Docs: Validating webhook deliveries
- AWS: Signature Version 4 for API requests
Related NHI Mgmt Group resources: Webhook Secrets Security Guide · JWT Security Guide · DMARC, SPF and DKIM Guide · D3-BMA Bus Message Authentication · MITRE D3FEND Guide