Use application-level encryption for data at rest and in application workflows, not just TLS in transit. Separate keys by tenant, dataset, or record type, and keep root material in hardware-backed controls where possible. The goal is to reduce blast radius if storage, certificates, or backend access are compromised.
Why This Matters for Security Teams
HTTPS protects data in transit, but it does not solve the larger problem of who can read sensitive platform data once it lands in storage, queues, logs, analytics pipelines, or administrative tooling. That is why current guidance from the NIST Cybersecurity Framework 2.0 and NIST control baselines treats protection as a lifecycle issue, not a transport-only problem. Security teams need to think about exposure paths across backups, replicas, support workflows, and cloud service boundaries.
The practical risk is blast radius. If a certificate, database account, or backend service is compromised, TLS alone does nothing for data already decrypted inside the application or available to privileged operators. Stronger protection comes from layering application-level encryption, key separation, and strict access governance so compromise of one component does not automatically expose everything. This is especially important for platform data that contains customer records, secrets, session material, or internal telemetry that can be stitched together into a larger compromise. In practice, many security teams encounter data exposure only after a storage bucket, admin console, or support export has already been abused, rather than through intentional data-minimisation design.
How It Works in Practice
Protecting sensitive platform data beyond HTTPS means encrypting it before it reaches shared infrastructure and controlling how it is decrypted after arrival. In mature environments, teams classify data by sensitivity, then apply different key scopes for tenant, dataset, environment, or record type. That makes a single compromise less useful to an attacker and supports cleaner revocation when keys or services are rotated.
At a minimum, this usually includes:
- Field-level or object-level encryption for highly sensitive attributes.
- Envelope encryption with a master key protected in hardware-backed controls or managed key services.
- Separate keys for production, non-production, and high-risk tenant groups.
- Restricted decryption paths so only approved services can access cleartext.
- Audit logging for key use, administrative access, and bulk export activity.
Security design should also reflect the control intent in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially around cryptographic protection, key management, access control, and auditability. Encryption is not useful if application services can freely unwrap data for every request, so teams should pair it with least privilege, short-lived credentials, and workload identity controls. For platform data that flows into search, analytics, or AI features, the decryption boundary should be explicit and reviewable.
Operationally, the goal is to ensure that a breach of one layer does not automatically reveal the entire dataset. That means designing for segmented keys, controlled decryption, and traceable use of sensitive records across the platform. These controls tend to break down when legacy services share one broad decryption key because rotation, segmentation, and revocation become operationally impractical.
Common Variations and Edge Cases
Tighter encryption often increases operational overhead, requiring organisations to balance stronger containment against latency, service complexity, and recovery effort. Best practice is evolving where platforms use search indexing, data lakes, or AI pipelines that need partial access to sensitive records.
One common edge case is analytics. Teams may need to preserve queryability while still limiting exposure, which can lead to tokenisation, format-preserving encryption, or selective masking rather than full-field decryption everywhere. Another is multi-tenant SaaS, where a single platform may need tenant-level key isolation for higher-risk customers while using shared controls for lower-risk workloads. There is no universal standard for this yet, so the policy decision should be based on threat model, regulatory exposure, and tenant expectations.
Another boundary case is backup and disaster recovery. Data encrypted at the application layer still needs recoverable key material, but recovery access must not become a hidden bypass for normal production controls. The same applies to support and incident response workflows, where temporary access is often necessary but should be time-bound, logged, and reviewed. Where identity or privileged access governance is weak, encryption only delays exposure rather than preventing it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Data protection requires encryption beyond transport to reduce exposure at rest. |
| NIST SP 800-53 Rev 5 | SC-28 | Information at rest protection directly supports application-level encryption design. |
| NIST Zero Trust (SP 800-207) | Zero trust reinforces explicit, per-request access to decrypted data. |
Protect sensitive data with layered encryption and limit cleartext access to approved paths.
Related resources from NHI Mgmt Group
- How should security teams protect vector databases that contain sensitive AI data?
- How should security teams protect sensitive data across SaaS and GenAI workflows?
- How should security teams protect sensitive data in AWS without relying on encryption alone?
- How should security teams protect sensitive data stored by mobile apps on iOS?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
