Topic starter
18/08/2026 2:56 pm
TL;DR: CRA readiness depends on operational controls across the software supply chain, from SBOMs and CI/CD hardening to policy-driven deployment governance, because documentation alone will not satisfy auditors or reduce exposure, according to Kusari. The core shift is from checklist compliance to measurable traceability, accountability, and enforced security across development pipelines.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “The Top 10 To-Dos for CRA Compliance Right Now”.
Key questions
Q: What fails when software supply chain controls are only documented for CRA readiness?
A: Documentation alone fails because auditors and regulators need proof that controls were enforced in the pipeline, not just described on paper.
Q: Why do software build and deployment systems matter to CRA compliance?
A: They matter because they decide which code becomes trusted release material.
Q: What are the signs that SBOM governance is not working well enough?
A: Common warning signs include missing dependencies, stale component inventories, release packages that do not match the recorded bill of materials, and no clear owner for updates when vulnerabilities are disclosed.
Practitioner guidance
- Build a live software supply chain inventory Map first-party code, open source libraries, vendor components, and CI/CD workflows so the compliance baseline reflects how software is actually produced and shipped.
- Automate SBOM generation and maintenance Generate machine-readable SBOMs continuously, include transitive dependencies, and tie them to vulnerability and license updates so the inventory stays audit-ready.
- Harden build and release identities Restrict pipeline accounts, rotate secrets, isolate build environments, and require signed artifacts before any deployment reaches production.
Bottom line: CRA readiness is not achieved by documentation alone because software supply chain controls have to be enforced inside the build and release process.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:39 pm
CRA readiness is fundamentally a software identity governance problem. The article is framed as compliance guidance, but the operational centre of gravity is trust in build accounts, signing keys, deployment approvals, and third-party dependencies. That makes this more than SDLC hygiene. It is a question of who and what is allowed to create, attest, and release software, and under what evidence. Practitioners should treat software release authority as a governed identity function, not a developer convenience.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should teams prioritise deployment policy or vulnerability scanning first for CRA?
A: Teams should prioritise deployment policy when untrusted or unsigned artifacts can still reach production, because blocking bad releases reduces exposure immediately. Vulnerability scanning remains essential, but it is weaker if the organisation cannot stop risky software from being deployed in the first place.
👉 Read our full editorial: EU Cyber Resilience Act readiness means governing software supply chains