Topic starter
07/11/2026 11:48 am
TL;DR: Signing teams need evidence trails, not just protected keys, because auditors and CSIRTs can demand proof of custody and misuse response, according to AppViewX’s analysis of NIS2 code signing. For practitioners, governance now has to join cryptography, approval flow and incident reporting.
Editorial analysis by NHI Mgmt Group, based on content published by AppViewX: “Understanding The NIS2 Requirements For Code Signing Teams”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: NIS2 brings code signing into the same governance frame as incident reporting, supplier assurance and management oversight.
Glossary terms: NIS2, Code-Signing Key, Certificate Revocation, Hardware Security Module
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/11/2026 11:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: NIS2 makes code signing evidence a governed control for audits