How should teams govern code signing keys under NIS2?

What governance of code signing keys needs to prove under NIS2

Code signing keys should be treated as regulated machine identities with clear ownership, approval authority and lifecycle control. Under NIS2, the practical test is not only whether the private key is protected, but whether the organisation can demonstrate who controlled it, who could use it, when it was revoked and how misuse would be reported and contained.

That means governance needs to cover the full chain of custody, from creation to retirement. A code signing key that exists without a named owner, an approval path and a revocation procedure is already a governance weakness, even if it has not been abused. The evidence trail matters because NIS2 places weight on accountability, incident handling and the ability to show that controls worked in practice.

For teams that need a deeper operational model, Cryptographic Key Management Guide is the clearest internal reference for key lifecycle, key inventory and protection expectations.

How to structure control, custody and approval around the key

The most defensible model is to separate authority, custody and release. One team should own the policy, another should operate the signing workflow, and no single person should be able to create, export, approve and use the same signing key without oversight. That reduces the chance of silent misuse and makes later audit reconstruction possible.

Approval should be tied to change events, not handled as an informal courtesy. A code signing key should not be treated like a routine secret that can be copied into a developer workstation or left in a build pipeline without strong release controls. Access should be limited to the smallest set of systems and roles that actually need to sign artefacts, and the use of HSMs or equivalent protected storage is usually the right default for production-grade signing keys.

Where the organisation operates software release pipelines, the signing step should be explicitly separated from build and test activity. That helps avoid accidental key exposure through broad CI/CD permissions and makes it easier to prove that signing happened in a controlled environment rather than wherever the artefact was assembled.

The practical value of this model is easier to see in breach cases. Coupang Signing Key Breach shows why offboarding, revocation and custody controls matter when a signing key remains valid longer than it should.

What audit and incident readiness should look like

Under NIS2, teams should assume that key governance will be judged through evidence as much as through design. If a key is suspected of misuse, the organisation should be able to show when it was issued, who approved it, where it was stored, which systems used it, whether any exports occurred and when it was rotated or revoked. That record is essential for incident reporting and internal accountability.

Revocation procedures should be pre-decided, tested and fast enough to support operational deadlines. If a signing key is compromised or leaves the approved trust boundary, the response is not just to replace the key. Teams may also need to invalidate signed artefacts, publish revocation notices, inspect release channels for tampered content and check whether any attacker could still rely on cached trust decisions.

Earlier compromise matters because signed malicious content can continue to be trusted after the initial intrusion is gone. NVIDIA code-signing certificates stolen 2022 is a useful example of why revocation speed and downstream trust cleanup are part of the control, not an afterthought.

Risk and Threat Considerations

Code signing keys are attractive because they convert compromise into trust. If an attacker obtains a signing key, they may be able to publish software, updates or drivers that look legitimate to users, controls and downstream systems. The risk is amplified when revocation is slow, when the key is reused across environments, or when release systems cannot prove exactly where the key was used.

Failure mechanism: Weak custody, excessive access or poor offboarding allows a signing key to be copied, reused or left valid after compromise, so signed artefacts remain trusted even after the original control failure is known.

Impact: Malicious or altered software can inherit the organisation's trust, which can extend the incident into customer environments, distribution channels and regulatory reporting obligations.

Practitioner Guidance

What to prioritise: Start with ownership, custody and revocation, because those three elements determine whether the organisation can actually govern the key or only store it. If the team cannot name the approver, the operator and the revocation path, the control is not yet operational.

What to verify: Confirm that the signing workflow produces durable evidence for issuance, approval, use and retirement, and that the evidence is retrievable quickly enough for incident reporting. Also verify that emergency rotation can happen without waiting on a single administrator or a manually rebuilt pipeline.

Decision rule: If the key can sign production artefacts, treat it as a high-value regulated credential and give it stronger controls than ordinary application secrets. If a key is shared across teams, environments or release paths, treat that as a risk indicator rather than a convenience.

Practitioner takeaway: Under NIS2, code signing key governance is really a test of whether the organisation can prove trust, not merely maintain trust. The key should be controlled like a high-consequence identity with traceable authority, fast revocation and incident-ready evidence.

Related resources from NHI Mgmt Group

• How should security teams govern signing keys in container pipelines?
• How should security teams protect code signing keys used for firmware and software updates?
• What breaks when code signing keys are shared across build systems?
• How should organisations govern code signing certificates for software releases?