Software assurance: make the product evidence usable

At a glance

Start with a product and release version. Connect components, build provenance, signing approval, support commitments, and vulnerability decisions to that record.
Treat CRA reporting readiness and product conformity as separate workstreams with different dates and owners.
Use shared security services where they help, while keeping product accountability, evidence access, and recovery explicit.

Start with the product a customer actually receives

A security team may have a signing service, a component scanner, and a vulnerability queue yet still struggle to explain one shipped product. The records exist in different places. A release name means one thing to engineering, another to support, and something else to the legal entity making the market claim. My starting point is a single product version and a request to reconstruct its release.

Choose a product that includes the awkward dependencies: firmware, a mobile application, a cloud service, or a component supplied by another company. Ask who approved the release, what was tested, which components were included, and how an affected customer would receive a security update. The gaps in that reconstruction are the first improvement backlog.

A useful evidence chain is accessible to an authorized reviewer without relying on the person who happened to assemble the release. It should also be narrow enough to avoid distributing private signing material, customer data, or sensitive vulnerability details to everyone who asks for a compliance packet.

Set the CRA boundary before selecting controls

The CRA concerns products with digital elements made available on the EU market, subject to its scope and exclusions. Remote processing is included when its software is developed by or under the manufacturer’s responsibility and its absence prevents a product function. Medical devices governed by the MDR or IVDR are excluded. Free and open-source software needs a careful commercial-activity assessment; neither a free price nor an open-source label answers the scope question.

The main requirements apply from 11 December 2027. Manufacturer reporting obligations apply from 11 September 2026. Determine the product category and appropriate conformity-assessment route with the responsible product and legal owners. A generic category label or a vendor certificate does not settle that decision.

Connect six records to every important release

This is an operating design for teams to adapt, rather than a complete list of statutory documentation. Keep the links stable as records move between engineering, security, operations, and support. A dashboard that only counts documents will miss broken relationships.

Record	What a reviewer should be able to establish	Suggested owner
Product boundary	Version, intended use, supporting services, support commitment, and accountable manufacturer.	Product management
Component record	Included dependencies, versions, origins, and the decisions on relevant vulnerabilities.	Engineering and product security
Build evidence	Source revision, build process, artifact digest, and provenance available for verification.	Build engineering
Release authorization	Who could sign, what they approved, how keys were protected, and which artifact was released.	Release owner
Distribution and update	What customers received, how authenticity is checked, and how failed updates recover.	Operations and support
Response history	Reports, triage decisions, remediation, communication, and closure evidence.	Product security response team

Make signing an accountable release decision

A valid signature demonstrates a relationship between an artifact and a signing key under the verifier’s trust assumptions. It does not establish that the artifact is safe, that its source was reviewed, or that its release was authorized. Put those decisions into the workflow surrounding the signature.

For a representative release, trace who can request a signature, what workload identity they use, which policy evaluates the request, and where the authorization is recorded. Separate ordinary build execution from permission to approve a production release. Protect keys according to risk, constrain signing requests, and make emergency revocation and replacement testable.

NIST’s Secure Software Development Framework can help organize development practices. SLSA provides a framework for reasoning about supply-chain integrity and provenance. Use them to structure evidence and improvement; neither substitutes for product-specific vulnerability analysis or a CRA conformity decision.

Prepare the reporting path before the clock starts

From 11 September 2026, the reporting trigger is an actively exploited vulnerability or a severe incident affecting product security, not every newly assigned CVE. The Commission’s reporting guidance describes submission through the single reporting platform to the designated coordinating CSIRT and ENISA. Establish who determines the trigger, who submits, and who covers the role outside business hours.

Stage	Actively exploited vulnerability	Severe incident
Early warning	Within 24 hours of awareness.	Within 24 hours of awareness.
Notification	Within 72 hours of awareness.	Within 72 hours of awareness.
Final report	Within 14 days after a corrective or mitigating measure becomes available.	Within one month after submission of the 72-hour incident notification.

Share capabilities without losing accountability

Common services can reduce duplicated work across product teams: signing, artifact storage, component inventories, update distribution, vulnerability intake, and evidence retention. The useful design has a consistent interface and policy boundary while allowing a product owner to explain what applies to their release.

Buy, build, or combine these capabilities according to the operating boundary. A managed signing service may reduce key-management work while leaving release approval with the manufacturer. An internal platform may offer tighter integration but require explicit staffing for availability, patching, and recovery. A tool’s feature list is not an ownership model.

Use the same records across buyer questionnaires and regulatory work where the mappings fit. Keep a separate determination for each applicable regime. Evidence reuse does not automatically make a product compliant with the CRA, NIS2, the AI Act, or sector-specific rules.

Measure readiness with an evidence drill

Treat the ladder as a planning aid. A high score in one team cannot compensate for an unsupported product or a missing conformity obligation elsewhere. Record exceptions, their owners, and when they will be revisited.

Stage	Observable behavior	Next proof to obtain
Fragmented	Release evidence is assembled manually from individual teams.	Reconstruct one shipped version and name each record owner.
Connected	Product, build, signing, and vulnerability records can be followed.	Run an affected-component investigation from report to customer population.
Repeatable	Release gates and response procedures run through defined workflows.	Exercise key compromise, failed update, and out-of-hours escalation.
Sustained	Product changes and support obligations update the evidence continuously.	Sample old and new releases; verify records survive team and supplier changes.

Choose a narrow starting point and prove it works

Address the near-term reporting date first. Confirm the accountable manufacturer, coordinating authority, submission access, deputies, and escalation path. Run the timed exercise before relying on the procedure.
Choose one product and reconstruct one shipped version. List the missing or disconnected records, then assign owners and a date for each repair.
Run two practical drills: an affected dependency and a compromised signing credential. Follow each through release decisions, customer communication, and recovery.
Agree on a common evidence model and the interfaces shared services must support. Include export, access controls, retention, service failure, and provider exit.
Expand only after the pilot produces evidence a reviewer can follow. Track response latency, evidence retrieval time, failed handoffs, and unresolved product exceptions.

Questions to take back to your team

Can we reconstruct one shipped release without asking its original developer?
Who decides whether a vulnerability or incident meets a reporting trigger, including at night?
Can an unauthorized workload obtain a production signature?
Can we identify affected customers and deliver a recoverable update?
Which conformity decisions remain open, and who owns each one?

Sources & further reading

European Commission — CRA legislative summaryScope, manufacturer responsibilities, conformity, and application dates.
European Commission — CRA reporting obligationsReporting triggers, platform, and staged notifications.
Regulation (EU) 2024/2847 — Cyber Resilience ActAuthoritative text. Article 14 distinguishes final-report clocks; use the full text for product-specific determinations.
NIST SP 800-218 — Secure Software Development FrameworkA structure for secure development practices.
SLSA specification, version 1.2Supply-chain integrity and provenance; not a claim that an artifact is vulnerability-free.

A personal field guide. The checklists and operating frameworks are my recommendations; the linked authorities define their own requirements and scope. Review product and jurisdiction-specific obligations against the current source material.