Transport encryption protects a message only between two hops; once it sits in a mailbox, a queue or a log, anyone with access to that store can read it. MITRE D3FEND names the countermeasure Message Encryption (D3-MENCR) and defines it as "Encrypting a message body using a cryptographic key." It sits under the Harden tactic as a child of Message Hardening (D3-MH), next to Message Authentication (D3-MAN) and Transfer Agent Authentication (D3-TAAN), and the digital artefact it acts on is the Digital Message. This card explains the asymmetric and symmetric patterns D3FEND describes, the standards that implement them for email, chat and application messages, how to verify encryption is real, and its limits. It is for messaging, platform and application security teams. Email-specific deployment detail lives in the OpenPGP and S/MIME Email Encryption Guide and is not repeated here.
Key takeaways
- It protects the body, end to end. D3-MENCR encrypts the message itself, so it stays protected in storage and on relays that transport encryption does not cover.
- D3FEND maps no ATT&CK techniques to it. D3FEND 1.6.0 lists no related offensive techniques; D3FEND's data relates it to the ATT&CK mitigation M1041 Encrypt Sensitive Information.
- Use authenticated encryption. S/MIME 4.0 states EnvelopedData gives confidentiality only and ciphertext can be altered undetected; prefer AuthEnvelopedData or AEAD content encryption, and add signing for sender authentication.
- Headers usually stay in clear. Unless the client wraps the full message, Subject, From, To and other metadata remain readable.
- Keys are the control. Private keys on many devices, service encryption keys and certificate trust need lifecycle management, as D3FEND's considerations stress.
D3-MENCR at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-MENCR (d3f:MessageEncryption) |
| Tactic | Harden |
| Parent technique | Message Hardening (D3-MH) |
| Siblings | Message Authentication (D3-MAN), Transfer Agent Authentication (D3-TAAN) |
| Digital artefact | encrypts Digital Message |
| Patterns named by D3FEND | Asymmetric (X.509 certificates; S/MIME and PGP named) and symmetric (key shared via an exchange such as Diffie-Hellman; pre-shared or derived keys for message buses) |
| D3FEND reference | IETF RFC 3851, S/MIME 3.1 (obsoleted by RFC 5751, which RFC 8551 in turn obsoletes) |
| Related ATT&CK mitigation in D3FEND data | M1041 Encrypt Sensitive Information |
| ATT&CK techniques related in D3FEND | None in D3FEND 1.6.0 (checked November 2026) |
How it works
Asymmetric pattern
D3FEND describes the sender encrypting with the recipient's public key, usually from an X.509 certificate, and the recipient decrypting with the private key. In practice standards use hybrid encryption: a random content key encrypts the body and the public key protects that content key. RFC 8551 (S/MIME 4.0, Standards Track, April 2019) requires agents to support AES-128 GCM and AES-256 GCM for content, recommends ChaCha20-Poly1305, keeps AES-128 CBC as a requirement being phased down, and requires ECDH ephemeral-static key agreement for P-256 and X25519, with RSA encryption phased down and RSAES-OAEP recommended. RFC 9580 (OpenPGP, Standards Track, July 2024) obsoletes RFC 4880 and introduces version 6 keys and a version 2 encrypted and integrity-protected data packet.
Symmetric pattern
Both parties use the same key, agreed through a key exchange or provisioned in advance. D3FEND notes that for low-latency systems such as a message bus a pre-shared or derived symmetric key is typical to keep overhead down. For group chat, RFC 9420 Messaging Layer Security (MLS, Standards Track, July 2023) gives members shared group keys with forward secrecy and post-compromise security, for groups from two to thousands of members. See the End-to-End Encryption and Messaging Protocols Guide.
Message encryption versus transport encryption
| Question | Message encryption (D3-MENCR) | Transport encryption (TLS, encrypted tunnels) |
|---|---|---|
| What is protected | The message body, wherever it goes | The connection between two endpoints |
| Readable at relays and servers | No, unless they hold a recipient key | Yes, at every hop that terminates the connection |
| Readable in storage | No, unless decrypted and stored again | Yes, unless stored data is separately encrypted |
| Metadata (headers, routing) | Usually visible | Hidden on the wire, visible at endpoints |
| Server-side scanning, search, journaling | Blocked unless an approved key escrow or gateway decrypts | Works normally |
| Fits when | Sensitive content crosses systems you do not fully trust, or must stay protected at rest in mailboxes and queues | Default for every connection; always needed alongside message encryption |
Where it is implemented
| Message type | Standard or feature class | Notes |
|---|---|---|
| Email between people | S/MIME (RFC 8551); OpenPGP (RFC 9580) | D3FEND notes separate settings are often needed per client: webmail, desktop and mobile |
| Email via a gateway or platform service | Gateway-based or platform message encryption products | Decryption happens at a service, not the recipient's device: a different trust model. See the Email Encryption buyer's guide |
| Chat and group messaging | Signal protocol family; MLS (RFC 9420) | Keys agreed per conversation or group, with ratcheting |
| Application and API payloads | JSON Web Encryption (RFC 7516, Standards Track, May 2015) | The content encryption ("enc") algorithm must be AEAD; compact form has one recipient, JSON form supports several |
| Message buses and queues | Payload encryption in the producer with a symmetric key from a key management service | D3FEND names latency and CPU as the critical factor for real-time buses |
For integrity and sender authentication, which encryption alone does not give, see D3-MAN Message Authentication.
Where identity fits
Every message encryption key belongs to an identity. For people that is a certificate tied to a mailbox; for services it is a key held by a producer, consumer or API client, which is a non-human credential. D3FEND's considerations name the risks: private keys copied between devices, compromised keys and untrusted certificate authorities. Keep service encryption keys in a key management service or secrets manager with one owner per key, rotate them, and grant decrypt rights only to consumers that need the plaintext. See the Envelope Encryption and KMS Integration Patterns Guide and the Kafka Credentials Security Guide.
Implementation steps
- Classify flows. Identify messages that carry data needing protection beyond transport: regulated personal data, credentials, legal and financial content, and payloads that sit in shared queues.
- Pick the standard per flow. S/MIME where certificates are already managed; OpenPGP for partners that use it; MLS or Signal-based tools for chat; JWE or producer-side payload encryption for applications and buses.
- Choose authenticated modes. AES-GCM or ChaCha20-Poly1305 for content, AuthEnvelopedData in S/MIME, AEAD "enc" values in JWE. Sign as well when the receiver must know who sent it.
- Decide on header protection. RFC 8551 lets a sender wrap the full message in a message/rfc822 part so headers such as Subject are protected; agree whether clients will do this and train users not to put sensitive data in subjects otherwise.
- Set up key management. Certificate issuance, escrow for decryption keys where policy or eDiscovery requires it, recovery, revocation and rotation for service keys.
- Configure every client. Follow D3FEND's warning: set encryption on webmail, desktop and mobile clients separately, and test each one.
- Pilot and roll back safely. Start with one group or one queue, keep the old path available for a defined period, and keep decryption keys for past messages after rotation so stored messages stay readable.
How to verify it works
- Read the stored copy: inspect the message as stored on the server, in the queue or in the log. The body must be ciphertext, for example an application/pkcs7-mime part with smime-type authEnveloped-data, or a five-part JWE compact string.
- Tamper test: alter a byte of the ciphertext. With authenticated encryption, decryption must fail.
- Wrong-recipient test: a party without the key, including administrators of relays, must not be able to read the body.
- Client coverage test: send and read from every supported client and mobile platform.
- Key recovery drill: restore a user's or service's decryption key from escrow and read an archived message.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Classified flows with message encryption enforced | 100% of flows marked as needing it | Coverage |
| Encrypted messages using an authenticated mode | 100% for new messages | Removes undetected ciphertext tampering |
| Certificates and service keys with owner and expiry recorded | 100% | Keys are credentials with a lifecycle |
| Expired or revoked keys still in use | Zero | Stops silent failure and use of compromised keys |
| Key recovery drill success | Pass at each scheduled drill | Proves stored messages stay readable |
Limits, bypasses and failure patterns
- Confidentiality without integrity: RFC 8551 warns that EnvelopedData ciphertext can be altered undetected unless authentication is also applied. Legacy CBC-only deployments carry this risk.
- Metadata exposure: sender, recipients, subject, timestamps and sizes often remain visible and can be sensitive on their own.
- Endpoint compromise: plaintext exists on the sender's and recipient's devices; malware or a compromised mailbox session that reads decrypted messages is outside what D3-MENCR protects.
- Key sprawl: private keys exported to many devices, and shared symmetric keys across many producers, widen the blast radius of one leak.
- Silent fallback: clients that send in clear when no recipient certificate is found defeat the policy. Configure "encrypt or block" for flows that require it.
- Lost keys: without escrow or recovery, archived messages become unreadable, which turns a key loss into data loss.
Related ATT&CK techniques
D3FEND 1.6.0 lists no ATT&CK techniques for D3-MENCR, and its data relates the technique to M1041 Encrypt Sensitive Information. In NHI Mgmt Group's view, not D3FEND's mapping, message encryption reduces what an attacker gains from T1040 Network Sniffing and T1557 Adversary-in-the-Middle, and from T1114 Email Collection where the collector does not also hold the recipient's private key.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 Transmission Confidentiality and Integrity | Protecting message content in transit |
| 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 | SC-28 Protection of Information at Rest | Messages stay encrypted in mailboxes and queues |
| NIST CSF 2.0 | PR.DS-01, PR.DS-02 | Data at rest and data in transit protected |
| NIST SP 800-177 Rev 1 | Trustworthy Email, content security | S/MIME encryption and certificate distribution for email |
| MITRE ATT&CK | M1041 | Related mitigation in D3FEND data |
| MITRE D3FEND | D3-MH (parent), D3-MENCR, D3-MAN, D3-TAAN | Harden tactic, message level |
Mail server authentication is covered in D3-TAAN Transfer Agent Authentication, and the file-level equivalent in D3-FE File Encryption.
Practitioner checklist
- List message flows that need protection beyond transport encryption.
- Choose S/MIME, OpenPGP, MLS or JWE per flow and document why.
- Use authenticated encryption modes and sign where sender identity matters.
- Decide on header protection and keep sensitive data out of unprotected headers.
- Configure and test encryption on every client type.
- Manage certificates and service keys with owners, expiry, escrow and rotation.
- Block, rather than silently send in clear, when encryption is required and not possible.
- Run tamper, wrong-recipient and key recovery tests.
Standards and references
- MITRE D3FEND: Message Encryption (D3-MENCR)
- IETF: RFC 8551 S/MIME Version 4.0 Message Specification
- IETF: RFC 9580 OpenPGP
- IETF: RFC 9420 The Messaging Layer Security (MLS) Protocol
- IETF: RFC 7516 JSON Web Encryption (JWE)
- NIST: SP 800-177 Rev. 1 Trustworthy Email
- IETF: RFC 3851 S/MIME Version 3.1 Message Specification (obsolete)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-8, SC-12, SC-13, SC-28)
Related NHI Mgmt Group resources: OpenPGP and S/MIME Email Encryption Guide · End-to-End Encryption and Messaging Protocols Guide · D3-MAN Message Authentication · M1041 Encrypt Sensitive Information · MITRE D3FEND Guide