TL;DR: NIS2 now pushes code signing into audit territory, with signing keys, MFA, supplier verification and incident-report evidence all tied to Article 21 and Article 23 obligations, according to AppViewX analysis. Compliance becomes a documentation problem as much as a cryptographic one, because auditors and CSIRTs need traceable proof of custody and misuse.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's report: NIS2 makes code signing a governed evidence control, with key custody, MFA, supplier checks and incident reporting all tied to compliance.
Why it matters: Security and IAM teams need to treat code signing keys as regulated machine identities, because custody, approvals and revocation records now shape both resilience and auditability.
By the numbers:
- 23 of 27 EU member states had notified full NIS2 transposition by July 8, 2026, while the European Commission referred the other four to the EU Court of Justice.
Context
NIS2 turns code signing into a governance issue, not just a build or release concern. Once a signing key can affect software trust, firmware trust, or supplier update trust, its custody, approval path, and revocation history become part of the organisation’s control evidence.
For organisations in covered sectors, the practical question is whether signing controls can stand up to external scrutiny from auditors, competent authorities, and CSIRTs. That means the security model has to preserve not only cryptographic integrity but also proof of who approved a signature, when it was used, and whether misuse would be visible in time.
Key questions
Q: How should teams govern code signing keys under NIS2?
A: Teams should govern code signing keys as regulated machine identities with named owners, approval controls, revocation procedures and an evidence trail that supports audit and incident reporting. The key question is not only whether the private key is protected, but whether the organisation can prove custody, use and misuse handling under regulatory deadlines.
Q: What evidence do auditors need for code signing controls?
A: Auditors usually need proof that the private code signing key is protected, usage is restricted, and signed artefacts can be traced to an authorised release process. That evidence includes key custody records, certificate lifecycle logs, signing logs, approval records, and revocation or rotation actions when misuse is detected.
Q: How do signed software updates become a supply chain risk?
A: Signed software updates become a supply chain risk when attackers can abuse the trusted signing key or the build pipeline to sign malicious code as if it were legitimate. The danger is not the signature itself, but stolen keys, compromised signing infrastructure, or unauthorised release approval that lets tampered updates pass trust checks.
Q: What should security teams do first after a code signing key is misused?
A: Security teams should first revoke or disable the compromised signing key, then quarantine any artefacts that may have been signed with it and preserve the signing records for investigation. They should also assess whether certificate revocation, key rotation, and release revalidation are needed before any further software is published.
Technical breakdown
Why code signing keys become regulated machine identities
A code signing key is not just a cryptographic asset. It is a machine identity that authorises software, firmware, or updates to be trusted by downstream systems and customers. Under NIS2, that trust boundary matters because compromise or misuse can become a significant incident, especially when signed artefacts cross supplier and customer environments. The governance problem is therefore identity custody, not only key strength: who can sign, under what policy, with what approval trail, and with what revocation mechanics if the key is abused. See the Cryptographic Key Management Guide.
Practical implication: Treat signing keys as governed identities with named owners, traceable approvals and revocation procedures, not as developer convenience credentials.
How NIS2 evidence maps to signing operations
NIS2 Article 21 and Article 23 pull signing into the same control logic as broader incident governance. A signing platform must be able to show key inventory, approval records, signature timestamps, revocation status, and the files signed by a specific key. That evidence matters because reporting clocks start when the organisation becomes aware of a significant incident, not when it finishes investigating. In practice, the control is the record set: if a team cannot prove what was signed, by whom, and under which policy, it will struggle to demonstrate compliance after misuse.
Practical implication: Build signing workflows so every signature produces durable evidence for incident triage, reporting and audit review.
Why supplier verification belongs in the signing pipeline
NIS2 treats software supply chain trust as part of the same risk domain as internal signing. Verified signatures on third-party code and patches help establish integrity before a release reaches production, and that requirement extends the signing function beyond internal release control. This is where code signing becomes a supply chain control: it confirms provenance, reduces tampering risk, and supports the organisation’s obligation to assess suppliers. Without those checks, the signing process can protect a release artifact while still failing the broader governance test. See the OWASP Top 10 A08 Guide.
Practical implication: Insert signature verification into supplier intake and release workflows so trusted code is validated before deployment.
Threat narrative
Attacker objective: The objective is to turn malicious code into trusted software that can propagate through customer and supplier environments without immediate detection.
- Entry occurs when an attacker obtains or abuses a signing key, certificate, or approval path that can produce trusted code or firmware.
- Escalation follows when the attacker signs unapproved binaries or updates, allowing malicious content to inherit legitimacy inside customer environments.
- Impact lands when downstream systems install the signed payload and the organisation must revoke trust, trace distribution, and report the incident under regulatory clocks.
Breaches seen in the wild
- Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Code signing under NIS2 is an evidence discipline, not a tooling feature. The directive ties signing to incident reporting, supplier assurance and management oversight, which means the real control is the record chain behind each signature. A team that cannot prove key custody, approval and revocation cannot prove governance. Practitioners should treat signing telemetry as compliance evidence, not convenience logging.
Trusted software now sits inside the regulated identity perimeter. Once a signing key can legitimise software, firmware or patches, it behaves like a privileged machine identity with downstream authority. That shifts governance from patch-level integrity to lifecycle control over the signing credential itself. The implication is that signing teams must be managed with the same seriousness as other privileged identity holders.
Vendor supply chain checks extend code signing beyond the enterprise boundary. NIS2 makes supplier verification part of the security posture, so a signing workflow has to answer for third-party code as well as internal releases. This is where trust failures become distributed, because a signed artifact can move through multiple organisations before the defect is visible. Practitioners should assume the signing process now serves as a boundary control for the whole software chain.
Crypto-agility is becoming a governance requirement, not a future planning exercise. NIS2 and the implementing regulation push teams to maintain algorithm inventory, key lifecycle rules and replacement plans that can survive policy change and post-quantum transition. That turns signing policy into a living control set rather than a static document. The practical conclusion is that teams need a reusable governance model for algorithm change, certificate retirement and key replacement.
Signing evidence should be designed for incident clocks, not just routine audits. The 24-hour warning and 72-hour notification deadlines mean teams need to surface key IDs, misuse windows, revocation actions and affected file lists quickly. That is a different design target from end-of-quarter audit support. Practitioners should assume the most valuable signing evidence is the evidence that can be assembled while the incident is still unfolding.
From our research library:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: Cryptographic Key Management Guide
What this signals
Signing evidence will become a board-level governance artifact. As more sectors fall under NIS2, teams will need to connect release signing, certificate inventory and incident reporting into one control story. The pressure will be less about adopting a new cryptographic standard and more about proving that the organisation can answer questions quickly when trust is challenged.
Key-custody discipline is the new baseline for software trust. The practical shift is away from treating code signing as an isolated build-step and toward treating it as lifecycle-managed identity. That means owners, approvals, revocations and recovery evidence must be designed together, or the organisation will end up with strong signatures and weak accountability.
For practitioners
- Inventory every signing key and certificate Assign an owner, locate shadow keys in build systems and establish a single inventory that can be reconciled against releases and certificates.
- Move signing access behind MFA and approval Require MFA for signing requests and policy changes, then route every approval through a controlled workflow with durable logs.
- Verify supplier code before release use Check signatures on third-party components and patches before they enter build or deployment pipelines, and block unsigned artifacts.
- Design incident evidence around reporting clocks Make sure key IDs, revocation status, signed file lists and misuse windows can be produced within 24-hour and 72-hour reporting deadlines.
- Test whether internal keys need hardware protection Decide if internal signing keys should meet the certified-hardware baseline used for publicly trusted code signing keys and document the rationale.
Key takeaways
- NIS2 brings code signing into the same governance frame as incident reporting, supplier assurance and management oversight.
- The most important control is the evidence chain around each signature, not the signature itself.
- Teams need inventory, approval, revocation and reporting records that can survive both audit scrutiny and incident timelines.
Related NHI Mgmt Group resources: Cryptographic Key Management Guide · OWASP Top 10 A08 Guide · Incident Response Guide · Machine Identity, PKI and Certificate Lifecycle Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIS2 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Signing keys and approval paths confer trust authority that must be tightly limited under NIS2. |
| NHI-01 — Improper Offboarding | Misused signing keys must be revoked and retired quickly or their trust persists after control changes. | |
| NHI-02 — Secret Leakage | Signing keys and certificates become regulatory evidence liabilities once they leak or are misused. | |
| Recommendation — Apply least-privilege governance to signing keys and restrict who can approve, use and revoke them. Retire signing credentials immediately when ownership or trust status changes. Protect signing secrets from exposure in build systems, developer machines and logs. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article centers on stolen or misused signing credentials and the downstream impact of trusted malware. |
| Recommendation — Hunt for credential theft and signed-payload distribution patterns around signing infrastructure. | ||
| NIS2 | Article 21; Article 23 — Risk management measures; Incident reporting | NIS2 directly governs the signing controls and reporting obligations described in the article. |
| Recommendation — Map signing workflows to Articles 21 and 23 and verify the evidence needed for reporting is available. | ||
Key terms
- NIS2: The European Union's updated cybersecurity directive for essential and important entities. It requires organisations to demonstrate stronger cyber resilience through risk management, incident reporting, supply chain oversight, and access control, with identity governance playing a central role in how those obligations are proven.
- Code-Signing Key: A code-signing key is the private key used to create trusted signatures on software and updates. If it is stolen or misused, attackers can sign malicious code that may appear legitimate to users, platforms, and security controls.
- Certificate Revocation: Certificate Revocation is the act of marking a certificate as no longer trustworthy before its expiry date. Administrators revoke certificates after key compromise, misuse, or identity changes, and clients must check revocation status where possible, otherwise an attacker with a stolen private key may continue to present a valid-looking certificate.
- Hardware Security Module: A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org