Notifications
Clear all
Topic starter
20/08/2026 5:59 pm
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.
NHIMG editorial — based on content published by INTIGRITI: How Intigriti keeps your data safe with application-level encryption
By the numbers:
- 17 minutes and as quickly as 9 minutes, cly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 53% of organisations have experienced a security incident directly related to machine identity management failures.
- Only 38% have automated certificate lifecycle management in place.
Questions worth separating out
Q: How should security teams protect sensitive platform data beyond HTTPS?
A: Use application-level encryption for data at rest and in application workflows, not just TLS in transit.
Q: Why is key management as important as encryption itself?
A: Because encryption only protects data while the keys remain controlled.
Q: What should teams check before calling deletion secure?
A: Confirm that deletion removes recoverability, not just database rows.
Practitioner guidance
- Map the full key hierarchy Document which master keys, derived keys, and object-specific keys protect each sensitive dataset, then confirm who can retrieve each layer and under what conditions.
- Test data exposure after trust-anchor compromise Simulate root certificate interception, stolen credentials, and storage compromise to verify whether encrypted records remain unreadable outside the intended application path.
- Verify deletion through key destruction Audit whether record deletion actually destroys the keys needed to recover the data, including replicas, backups, and any escrow or recovery paths.
What's in the full article
INTIGRITI's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact application-level encryption flow used for submission, company, and researcher data.
- How master keys are rotated, how subkeys are derived, and how those choices affect recoverability.
- Why Google Cloud Hardware Security Modules were used for database key protection and what that changes for compromise assumptions.
- The secure deletion process for compliance-driven data destruction when keys are retired.
👉 Read INTIGRITI’s analysis of application-level encryption for platform data →
Application-level encryption for sensitive platform data: is HTTPS enough?
Explore further
20/08/2026 6:38 pm
Application-level encryption is a data-governance control, not just a cryptography choice. The value is not the cipher itself but the boundary it creates between transport, storage, and application access. For platforms that process sensitive submissions and identity-linked records, encryption only meaningfully reduces risk when key ownership, retrieval, and revocation are governed with the same discipline as access control. Practitioners should treat encryption as part of the identity and data control plane.
A question worth separating out:
Q: How do organisations know whether encryption is actually reducing risk?
A: They should test failure scenarios, not just configuration status. If a compromised certificate chain, stolen credential, or storage breach still leaves data unreadable, the control is working. If internal users can decrypt far more data than they need, the access model is too broad.
👉 Read our full editorial: Application-level encryption closes the gap beyond HTTPS
