Notifications
Clear all
Topic starter
21/08/2026 4:52 pm
TL;DR: From September 2026, the EU Cyber Resilience Act will require hardware and software providers to prove secure design, vulnerability handling, SBOM transparency, and controlled source-code access, according to KOBIL. The compliance challenge is not just regulatory paperwork, but whether product security, supply chain governance, and access control are operating as one system.
NHIMG editorial — based on content published by KOBIL: Cyber Resilience Act readiness for software and hardware providers
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should organisations control source-code access under the Cyber Resilience Act?
A: Organisations should treat source-code access as a high-risk privilege tier.
Q: Why do SBOMs matter for product security and compliance?
A: SBOMs matter because they show which components are present when a vulnerability emerges.
Q: What breaks when developer privileges are too broad in software supply chains?
A: Broad developer privileges weaken review discipline and make it easier for unauthorised or mistaken changes to enter shipped software.
Practitioner guidance
- Control privileged developer access Restrict access to critical source code, build systems, and release tooling to named identities with approved business need.
- Make SBOMs operational, not static Link SBOM generation to build and release pipelines so component inventories update with each release.
- Tighten vulnerability reporting workflows Define internal escalation paths so product vulnerabilities are triaged, assigned, and reported within the CRA time expectations.
What's in the full article
KOBIL's full article covers the operational detail this post intentionally leaves for the source:
- A CRA-oriented breakdown of which product classes and supplier roles are in scope for the regulation
- Operational guidance on SBOM documentation, verification, and change traceability across software components
- Specific recommendations for controlling access to critical source code and build systems
- Reporting and update workflow details for organisations that need to meet incident and patch deadlines
👉 Read KOBIL's analysis of Cyber Resilience Act readiness for software and hardware providers →
Cyber Resilience Act readiness: are supply chain controls keeping up?
Explore further
21/08/2026 5:10 pm
CRA readiness is fundamentally an identity governance problem. The article frames compliance around SBOMs, vulnerability reporting, and secure product design, but the control plane underneath is who can alter source code and release artefacts. That makes product security dependent on privileged access discipline, not just security policy. Practitioners should treat build and release identities as governed assets, not developer conveniences.
A question worth separating out:
Q: Who is accountable when a product fails CRA conformity or reporting expectations?
A: Accountability usually sits across product security, engineering, compliance, and legal, but one function must own the evidence chain. The best practice is to name a primary control owner for reporting readiness and a separate owner for conformity readiness, so responsibilities do not collapse into a shared but unmanaged obligation.
👉 Read our full editorial: Cyber Resilience Act readiness starts with software supply chain governance
