TL;DR: Sensitive platform data still needs application-level encryption to resist root-certificate interception, storage attacks, and data theft at rest, according to INTIGRITI. The security lesson is that multi-layered encryption only works when key hierarchy, compartmentalisation, and secure deletion are governed as operational controls, not assumptions.
At a glance
What this is: This is an analysis of why HTTPS alone does not fully protect sensitive platform data, and how application-level encryption reduces exposure to interception, storage compromise, and data theft.
Why it matters: It matters to IAM and security teams because data protection depends on how encryption, keys, and deletion are governed across the application and storage stack, not only on transport security.
Context
Application-level encryption is the practice of encrypting sensitive data before it reaches long-term storage, rather than relying only on transport-layer protection such as HTTPS. In multi-tenant platforms, that design matters because access, storage, and deletion are separate control problems, and a weakness in one layer can expose the whole data set.
For identity and access governance, the relevant question is not whether data is encrypted somewhere in the stack, but which identities can reach keys, decrypt specific records, and trigger deletion. That makes this topic relevant to NHI governance as well as human access control, because service access to key material can determine whether encrypted data remains protected in practice.
Key questions
Q: When is HTTPS not enough for sensitive platform data?
A: HTTPS is not enough when data remains valuable after it leaves the network path, such as in databases, backups, admin consoles, or multi-tenant workflows. In those cases, transport encryption protects transit but not storage, recovery, or backend access. Application-level encryption is needed when the data itself must remain confidential even if infrastructure or credentials are compromised.
Q: Why do layered encryption designs reduce breach impact?
A: Layered designs reduce impact because they separate the compromise of one key from the ability to decrypt everything. If master keys, derived keys, and user or company key wrappers are isolated, an attacker who reaches one layer still has to break the others. That turns a single failure into a narrower exposure instead of a full data collapse.
Q: What breaks when key destruction is not part of deletion?
A: Deletion becomes incomplete if the encrypted data still has surviving keys. Files, database rows, or backups may be removed, but the content can be recovered as long as a valid key remains available. Secure deletion only becomes effective when the relevant keys are destroyed and the retained data can no longer be decrypted.
A: Security teams should separate encryption by data class or tenant, automate key generation and rotation, and keep strong control over where root keys live. A good design uses envelope encryption, limits blast radius if one key is exposed, and preserves a clear audit trail. The goal is to make encryption part of the application workflow, not a manual specialist process.
Technical breakdown
Why HTTPS is not the same as end-to-end encryption
HTTPS protects data in transit by encrypting the connection between client and server, but it does not guarantee that data stays protected once it reaches the application or storage layer. If a trusted certificate authority path is subverted, a root certificate is installed, or an attacker reaches the backend, transport encryption no longer protects the payload in use or at rest. That is why security teams should treat HTTPS as one layer in a broader data protection model, not as a complete confidentiality control.
Practical implication: use application-level encryption when data remains sensitive after transit, especially in multi-tenant systems.
How rotating master keys and subkeys limit exposure
A layered encryption design separates a root or master key from derived subkeys used for specific objects, users, or workflows. That reduces blast radius because a compromise of one derived key does not automatically expose every encrypted record. Key rotation further narrows exposure by shortening the useful life of any key that may leak, while hardware-backed security modules keep the most sensitive material isolated from routine system access. The model only works if key derivation, storage, and rotation are tightly governed.
Practical implication: enforce key hierarchy and rotation as governance controls, not as back-end implementation details.
Why secure deletion depends on key destruction
Encryption only supports irreversible deletion if the data cannot be decrypted after retention ends. In practice, that means destroying the keys, not merely deleting the storage objects or database rows. Once the keys are gone, the encrypted data becomes computationally useless, which supports compliance and reduces the residual risk of stale copies, backups, or recovered media. This is especially relevant where platform data includes submissions, communications, or identity-linked records that must not survive beyond the approved retention period.
Practical implication: align retention policy with key destruction so deletion is real, not symbolic.
Threat narrative
Attacker objective: The attacker wants usable access to sensitive platform data despite HTTPS and storage controls, including submissions, communications, or identity-linked records.
- Entry occurs when an attacker intercepts traffic through a trusted root certificate path or reaches the storage layer where encrypted data is held.
- Credential or key access then becomes the pivot, because the attacker must obtain backend secrets, decryptable key material, or database-held submission keys.
- Impact follows if the attacker can decrypt sensitive platform data at rest or defeat the assumptions behind transport-only protection.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Application-level encryption is a data compartmentalisation control, not a cosmetic hardening layer. HTTPS reduces transport exposure, but platform data often becomes most vulnerable after it lands inside application workflows, databases, backups, and admin tooling. In multi-tenant systems, the real question is whether one compromise can reveal everything or only a narrow slice. Practitioners should treat compartmentalisation as the governing objective.
Key hierarchy is the governance boundary that makes encryption operationally meaningful. When a master key, derived keys, and per-user or per-company key wrapping are separated correctly, the compromise of one layer does not automatically collapse the rest. That is a stronger model than treating encryption as a binary on or off state. Identity teams should pay attention to which service accounts, workloads, and administrators can reach decryption material.
Secure deletion only works when key destruction is part of the lifecycle. Deleting records without destroying the keys leaves recoverability intact through backups, replicas, and retained exports. That means retention, offboarding, and destruction controls belong in the same governance conversation as encryption design. For IAM and NHI programmes, the key-management lifecycle is the control plane that determines whether data is actually gone.
Root-certificate interception exposes the limit of perimeter trust assumptions. Once a device trusts a malicious or compromised root, encrypted traffic can be decrypted and re-encrypted without the user seeing obvious failure. That makes transport security necessary but incomplete, especially for sensitive platform data handled across shared infrastructure. Security teams should assume that some data needs protection even after the TLS session ends.
What this signals
Compartmentalisation is the real control objective: when platform data is sensitive after transit, protection has to survive inside storage, backups, and administrative workflows, not just on the wire. That shifts the governance question from “is it encrypted?” to “what can still be decrypted if one layer fails?”
The practical signal for security programmes is that key ownership now matters as much as storage ownership. If service accounts or platform administrators can reach decryptable key material too broadly, the encryption model is weaker than it looks, even when the underlying cipher and transport are sound.
For practitioners
- Define encryption boundaries by data sensitivity Classify which platform data must remain encrypted after transit and which can rely on transport-layer protection alone. Use that classification to decide where application-level encryption is mandatory.
- Separate master keys from derived keys Use a key hierarchy that limits blast radius by deriving narrow-purpose keys from a protected root rather than sharing one universal decryptor across the platform.
- Govern key rotation as an access control Set rotation and rewrapping rules for master keys, subkeys, and service access to key material so that compromise windows do not remain open indefinitely.
- Make deletion depend on key destruction Tie retention, offboarding, and compliance deletion workflows to destruction of the relevant encryption keys so that removed data cannot be restored from retained copies.
Key takeaways
- Application-level encryption closes a gap that HTTPS cannot, because transport protection does not stop storage compromise, trusted-certificate interception, or backend data theft.
- The effective control is not encryption alone but encryption governance, including key hierarchy, rotation, compartmentalisation, and destruction.
- For identity and security teams, the key question is who can decrypt what, because access to keys determines whether protected data remains protected in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Encrypted platform data still depends on protecting the keys and wrapped secrets that make decryption possible. |
| NHI-07 — Long-Lived Secrets | The article emphasises rotating master keys and shortening the life of decryption secrets. | |
| Recommendation — Scan for exposed encryption material and revoke any leaked keys before they can decrypt stored platform data. Reduce exposure by rotating long-lived encryption secrets and limiting how long any decryptable key remains valid. | ||
| NIST SP 800-53 Rev 5 | SC-12 — Cryptographic Key Establishment and Management | The core control problem is governing the lifecycle of master keys and derived keys. |
| SC-28 — Protection of Information at Rest | The article is explicitly about protecting sensitive platform data once it is stored. | |
| Recommendation — Apply key establishment and management controls to govern generation, rotation, protection, and destruction of encryption keys. Encrypt stored data so that database or storage compromise does not expose sensitive content in plaintext. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest is Protected | Application-level encryption extends data protection beyond transport into storage and recovery states. |
| Recommendation — Verify that sensitive data remains protected at rest, including in backups, replicas, and archived copies. | ||
Key terms
- Application-layer encryption: Application-layer encryption means sensitive data is encrypted before it is written to storage, rather than relying only on disk or database encryption. The application decides when plaintext is created, while the encryption boundary is enforced outside the database, which reduces exposure from queries, exports, and backup copies.
- Key Hierarchy: A layered structure where master keys, derived keys, and object-specific keys protect different data scopes. It limits blast radius by ensuring one compromise does not automatically expose every record, tenant, or user context.
- Hardware Security Module: A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
- Secure Deletion: The process of making data irrecoverable, usually by destroying the keys needed to decrypt it rather than relying only on record removal. It is only reliable when backups, replicas, and recovery paths are included in the deletion design.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, when your programme needs stronger control over key access and identity governance.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org