Who is accountable when cryptographic keys on z/OS are exposed or mishandled?

Accountability usually sits with the organisation that owns the protected data and the platform operations team that administers the key lifecycle. Security leadership should define policy, operations should execute controls, and compliance should verify evidence. In practice, ownership must be explicit across creation, use, backup, recovery, rotation, and retirement.

Why This Matters for Security Teams

On z/OS, exposed or mishandled cryptographic keys are not just a technical mistake, they are a governance failure with direct impact on data confidentiality, transaction integrity, and auditability. Because keys often protect high-value workloads and legacy integrations, ambiguity about who owns the lifecycle can leave gaps between platform administration, application teams, and security oversight. That is exactly the kind of split responsibility that turns a recoverable issue into a reportable incident. NIST SP 800-53 Rev. 5 Security and Privacy Controls makes clear that access control, audit, and key management responsibilities must be defined and evidenced, not implied.

NHI Mgmt Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows why this matters at scale: cryptographic material tied to non-human identities is frequently overexposed, poorly rotated, and weakly governed. The same operational pattern appears in key handling on z/OS when teams assume the platform protects them automatically. In practice, many security teams encounter accountability failures only after a key has already been used outside its intended boundary, rather than through intentional lifecycle governance.

How It Works in Practice

Accountability should follow the control plane, not the convenience of the team that touched the key last. In a mature z/OS environment, the organisation that owns the protected data remains accountable for the risk, while platform operations are accountable for secure administration of key stores, certificates, hardware security modules, and backup or recovery procedures. Security leadership sets policy, defines approval thresholds, and requires evidence. Compliance validates whether controls were actually followed.

Practically, this means assigning named owners for creation, activation, rotation, escrow, backup, restore, and retirement. It also means logging every administrative action, separating duties so no single operator can create and approve a risky exception, and ensuring emergency access is time-bound and reviewable. The NIST guidance on access control and audit logging is useful here because accountability is only defensible when the record shows who authorised what, when, and under which policy. NHIMG’s 52 NHI Breaches Analysis and the Microsoft Azure Key Breach research both reinforce the same lesson: once secrets or keys are exposed, unclear ownership slows containment and extends blast radius.

• Define a single accountable owner for each key domain, even if multiple teams operate it.
• Require documented approvals for issuance, export, and recovery actions.
• Track every lifecycle event with immutable logs and periodic review.
• Verify that rotation and retirement are enforced, not left to local practice.

These controls tend to break down when z/OS key custody is split across inherited mainframe processes, outsourced operations, and application teams with no shared policy vocabulary.

Common Variations and Edge Cases

Tighter key governance often increases operational overhead, requiring organisations to balance speed of recovery against the need for separation of duties and audit evidence. That tradeoff becomes sharper in hybrid estates, disaster recovery testing, and regulated environments where key export or restore workflows are unavoidable. There is no universal standard for this yet, but current guidance suggests the accountable owner should never change just because the operational location changes.

One common edge case is third-party operations support. Even when an external provider administers the platform, the organisation that owns the data still retains accountability for the risk outcome. Another is shared infrastructure where one key protects multiple applications; in that case, accountability should be assigned at the service or data domain level, not left to a generic infrastructure queue. A third case is legacy recovery access, where long-lived override keys are kept for emergencies. Best practice is evolving toward time-limited, heavily monitored access, because permanent break-glass credentials undermine auditability and encourage drift.

For broader NHI governance context, the operational patterns described in the Ultimate Guide to NHIs apply directly: if a credential or key can act on behalf of a system, it needs explicit lifecycle ownership. In real environments, accountability disputes usually surface during audits or incident response, not during design reviews.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access controls fail to meet mandated cryptographic standards?
• Who is accountable when exposed credentials on developer systems are not identified and triaged promptly?
• Who is accountable when a service account is over-privileged and customer data is exposed through support tooling?
• Who is accountable when an exposed internet-facing asset is discovered after a control failure?