Developers prevent Missing Encryption of Sensitive Data by encrypting sensitive data in transit and at rest, and by treating key management as part of the design. They should classify data, ensure secrets are not stored in plain text, and verify that databases, backups, logs, and API traffic use approved encryption controls. Review exceptions regularly and remove any unprotected storage.
How developers make encryption part of the application design
Missing encryption is usually a design and implementation failure, not a late-stage checkbox problem. Developers need to decide early which data classes require encryption, where encryption is mandatory, and which components are allowed to see plaintext. That includes application code, storage layers, message paths, backups, logs, and any API traffic that carries sensitive fields.
Good practice is to treat encryption as a system property, not just a database setting. The same data can be protected differently depending on whether it is being transmitted, stored, processed, or exported. For that reason, developers should align encryption choices with the data flow, and use the strongest control that still fits the workload, such as field-level protection for especially sensitive values and transport protection for service-to-service traffic. NHIMG’s Encryption Guide is a useful reference when choosing between at-rest, in-transit, and in-use protections.
Encryption also has to be paired with secret handling. If keys, API tokens, or database passwords are left in configuration files or source code, the encryption design collapses in practice. Developers should keep secrets out of plain text, use approved key custody methods, and make sure the application can rotate or revoke the material that protects encrypted assets without breaking availability.
Where encryption gaps usually appear in real systems
The most common failure is partial coverage: one layer is encrypted, but another remains exposed. A database may use encryption at rest while exported files, cached objects, backups, or operational logs still carry cleartext. Developers should assume that data will move across more than one trust boundary and check every place sensitive information is copied, transformed, indexed, or retained.
Another common weakness is using encryption controls inconsistently across services. Teams sometimes secure the main application path but forget batch jobs, admin tools, analytics pipelines, or support exports. That creates blind spots where sensitive data can leak even though the primary application appears compliant. A practical review should follow the actual data flow, not just the primary request path.
Misconfiguration is especially dangerous in cloud-native systems because defaults can expose more than the team expects. If storage rules, database settings, or logging defaults allow plaintext persistence, the problem is not the cipher, it is the deployment design. NHIMG’s Database Security Guide helps connect encryption with authentication, auditing, backups, and hardening choices that usually determine whether sensitive data remains protected.
When the question is broader data exposure rather than encryption alone, NHIMG’s Data Security Guide is a strong companion because it ties encryption to discovery, classification, and exposure reduction across the full data estate.
Choosing controls that hold up under maintenance and recovery
Encryption that works only in the happy path is not enough. Developers need to plan for rotation, recovery, restore operations, and exception handling before they ship. Backups, snapshots, exports, and archived logs should remain decryptable only by the systems and roles that genuinely need them, and the application should continue to function when keys are rotated or a service is restored from backup.
Key management is where many projects fail after launch. If the team cannot describe how keys are generated, stored, rotated, separated by environment, and retired, then encryption is not operationally trustworthy. The control must also be testable, meaning the team can prove that a plaintext copy is not surviving in a secondary system or a long-lived archive.
Teams that need deeper protection for sensitive fields should consider tokenisation or masking when the business process does not need the original value everywhere. NHIMG’s Tokenisation and Data Masking Guide is relevant when the goal is to reduce exposure, not simply encrypt the same value in more places.
For lifecycle discipline around keys and crypto material, NHIMG’s Data Retention and Secure Deletion Guide helps when encrypted data still has to be removed, expired, or cryptographically shredded on a defined schedule.
Risk and Threat Considerations
Missing encryption turns ordinary operational systems into high-value exposure points. If sensitive records, passwords, session material, or API payloads can be read in transit or at rest, an attacker who gains access to a server, backup set, log store, or network path can often escalate a small foothold into broader data compromise.
Failure mechanism: The weakness is usually not a broken cipher but an uncovered data path, a plaintext copy in logs or backups, or exposed credentials that let an attacker read protected data without needing to defeat the encryption itself.
Impact: Once plaintext is available anywhere in the workflow, confidentiality can fail across systems that were assumed to be protected, and recovery becomes harder because the exposure may already exist in replicated, archived, or exported copies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | key lifecycle — Key Management | Encryption design depends on secure key generation, storage, rotation, and retirement. |
| Recommendation — Define key lifecycle rules before release and rotate keys on a documented schedule. | ||
| OWASP ASVS | V11 — Cryptography | The subject is about protecting sensitive data with encryption in transit and at rest. |
| Recommendation — Verify cryptographic controls for data storage, transport, and sensitive fields. | ||
| CIS Controls v8 | CIS-3 — Data Protection | The answer centers on protecting sensitive data through encryption and reducing plaintext exposure. |
| Recommendation — Apply data protection safeguards to encrypt sensitive information and limit exposed copies. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | Encryption of sensitive data maps directly to cryptographic protection requirements. |
| IA-5 — Authenticator Management | Secrets and credentials must not be stored in plain text and need lifecycle control. | |
| Recommendation — Enforce cryptographic protection for sensitive data at rest and in transit. Manage and rotate secrets separately from protected data. | ||
Practitioner Guidance
What to verify: Confirm that encryption coverage matches the actual data lifecycle, not just the primary database. Check backups, exports, logs, message queues, and admin tooling for unintended plaintext, and verify that keys and secrets are managed separately from the data they protect.
Decision rule: If a system stores or transmits regulated, customer, or credential-bearing data, treat encryption as a release criterion. If a team cannot show where plaintext exists and who can decrypt it, the design is not ready.
Common mistake: Teams often assume “database encryption” solves the problem even when logs, caches, and integration paths still expose the same sensitive values. The better test is whether an operator or attacker can recover the data from any routine copy of the system.
Practitioner takeaway: Strong encryption is only meaningful when the surrounding data flow, key handling, and retention model are equally controlled; otherwise the weakest copy of the data becomes the real exposure point.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org