How should organisations approach cryptographic key protection for mainframe workloads and data at rest?

Why This Matters for Security Teams

For mainframe workloads, key protection is not only about encrypting datasets. It is about controlling who can generate, access, export, recover, and retire the keys that protect high-value records, batch jobs, and cross-system integrations. Weak governance often shows up as shared administrators, long-lived key material, and recovery processes that work technically but bypass meaningful oversight. That creates a direct path from routine operations to broad data exposure.

The problem is more acute when mainframes sit inside a wider hybrid estate. Keys are then touched by storage teams, z/OS operators, security engineers, and upstream application owners, which increases the odds of inconsistent policy. Current guidance from the NIST Cybersecurity Framework 2.0 and NIST control baselines treats cryptographic governance as a lifecycle discipline, not a one-time configuration. NHIMG research on machine identity complexity also shows why oversight matters: the Ultimate Guide to NHIs notes that 57% of organisations lack a complete inventory of their machine identities, which is exactly the kind of visibility gap that makes key custody harder to defend.

In practice, many security teams discover key misuse only after an outage, audit finding, or data access investigation rather than through intentional design.

How It Works in Practice

A workable model starts with separating the cryptographic functions that mainframe teams often collapse into one role. Key creation, approval, storage, export, rotation, and recovery should be distinct actions with distinct approvals. For data at rest, organisations should define which datasets require encryption, which keys protect them, where the key hierarchy lives, and how backup and disaster recovery replicas preserve the same trust model. For especially sensitive workloads, key access should be limited so that administrators can manage systems without being able to use the keys themselves.

Operationally, this usually means integrating mainframe key management with a hardware security module, restricting export paths, and requiring dual control for destructive or privileged operations. Many teams also map procedures to NIST SP 800-53 Rev. 5 Security and Privacy Controls so that cryptographic protection, access enforcement, and audit logging line up with broader governance requirements. Where mainframes exchange data with distributed systems, workload identity becomes important too. The SPIFFE workload identity specification is useful as a reference point for proving what a workload is before it is allowed to request or unwrap protected material.

• Assign separate custodians for key administration and operational support.
• Use short, documented approval paths for export and recovery actions.
• Keep a complete inventory of keys, protected datasets, and dependent workloads.
• Test restoration procedures so recovery does not create unreviewed privilege.
• Log key usage in a way that supports forensics and compliance review.

NHIMG’s Guide to SPIFFE and SPIRE is a useful reference for teams trying to connect workload identity, secret issuance, and runtime trust decisions across hybrid estates. These controls tend to break down when mainframe encryption is embedded in legacy batch chains that require broad operator access and cannot easily support segregation of duties.

Common Variations and Edge Cases

Tighter key control often increases operational friction, requiring organisations to balance recovery speed against the risk of overbroad access. That tradeoff is most visible in disaster recovery, third-party support, and emergency break-glass scenarios. The best practice is evolving, but current guidance suggests that emergency access should be time-bound, fully logged, and subject to post-event review rather than permanently exempt from control.

Another edge case is mixed ownership. Some mainframe environments are managed by infrastructure teams, while the encryption service is owned by security and the protected application is owned elsewhere. That split can cause gaps in accountability unless one party owns the full lifecycle. This is especially important for secret and machine identity sprawl, a theme echoed in NHIMG research and in the The State of Secrets in AppSec findings, which show how fragmented control undermines centralised governance. For teams modernising around NHIs, the Ultimate Guide to NHIs is the better place to anchor terminology and governance boundaries.

There is no universal standard for mainframe key governance maturity, so organisations should prioritise inventory, lifecycle control, and auditability before attempting advanced automation. The point is to make key use deliberate, attributable, and recoverable, not merely encrypted.

Related resources from NHI Mgmt Group

• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?
• How should organisations govern data and AI when teams are using models, agents, and fragmented data sources at the same time?
• Why does key ownership matter more as organisations move to cloud-based encryption services?
• How should organisations share sensitive files securely with external recipients without exposing data through email or messaging apps?