The useful way to evaluate CRA compliance software is not to ask how many checklist items it contains. Ask whether it can keep the manufacturer's cybersecurity requirements, risk decisions, security evidence, software bill of materials (SBOM), vulnerability work and release context connected over the product lifecycle.
That distinction matters because the Cyber Resilience Act (CRA) places obligations on the manufacturer, not on a software tool. A platform can structure work, preserve evidence and make gaps visible, but it cannot turn a dashboard score into legal conformity. The manufacturer still has to determine the requirements that apply to the product, perform the required engineering work, assemble technical documentation and complete the applicable conformity-assessment procedure.
The main CRA obligations apply from 11 December 2027, while Article 14 reporting obligations apply from 11 September 2026. The European Commission's July 2026 CRA guidance is non-binding but provides practical clarification for organisations preparing for those obligations.
Start with the operating model, not the checklist
A checklist is useful when it turns an obligation into owned work with evidence. It is weak when every item ends as a manually selected status such as “done” or “compliant” with no durable connection to the product state that justified the answer.
Before comparing products, map the workflow you actually need to run:
- which legal entity and manufacturer role is in scope;
- which products, variants and releases must be separated;
- who owns cybersecurity risk assessment;
- where security requirements and implementation records live;
- how SBOMs are produced and tied to releases;
- how vulnerability candidates are assessed and decisions are retained;
- how security testing and release evidence are captured;
- who assembles and reviews technical documentation;
- how post-market changes affect earlier conclusions; and
- which records must remain retrievable for authorities and internal review.
A tool should fit that operating model. Otherwise, the organisation may simply move an existing spreadsheet into a browser.
Criterion 1: product and release scope must be explicit
CRA evidence is meaningful only when its scope is clear. A risk assessment for one version, an SBOM for another and a penetration-test result for a third should not silently become one generic “product evidence” package.
The CRA requires manufacturers to conduct and document a cybersecurity risk assessment and to take its outcome into account throughout planning, design, development, production, delivery and maintenance. Technical documentation must describe the product and applicable versions sufficiently to support the conformity assessment.
When evaluating software, check whether it can distinguish at least:
- product from product family;
- variant from base product;
- release from later release;
- current evidence from superseded evidence;
- component inventory from vulnerability decision;
- assessment status from engineering implementation; and
- organisation-level process evidence from product-specific evidence.
A strong system should let a reviewer answer: which exact product state did this decision and this evidence apply to?
Criterion 2: risk assessment should behave like a lifecycle record
The CRA cybersecurity risk assessment is not merely an onboarding questionnaire. Article 13 requires it to be documented and considered across the product lifecycle, and manufacturers must update it as appropriate during the support period.
Software therefore needs more than a fixed risk matrix. Useful capabilities include:
- versioned risk records;
- documented assumptions and rationale;
- links from risks to security requirements or controls;
- ownership and review status;
- evidence showing how a risk was treated;
- change history when the product or threat context changes; and
- the ability to show which risk assessment supported a particular release.
The evaluation question is not whether the tool has a “risk module”. It is whether the module preserves the reasoning and evidence needed to understand how a product-security decision was reached.
Criterion 3: requirements need evidence, not just completion states
Annex I sets essential cybersecurity requirements for product properties and vulnerability handling. Annex VII requires technical documentation to contain information that demonstrates how the product meets the applicable essential requirements, including design and development information, cybersecurity risk assessment material and test reports.
For software selection, this creates a practical traceability requirement even though the CRA does not prescribe a particular tooling architecture.
Look for a chain such as:
requirement -> applicability decision -> implementation or control -> verification evidence -> reviewer decision -> product/release scope
A status field can be part of that chain, but it should not replace it. If a team marks a requirement “implemented”, the useful record is why it applied, what changed in the product, what evidence supports the claim, who reviewed it and which release carries that conclusion.
Criterion 4: SBOM and vulnerability handling should be connected
Annex I Part II requires manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used and machine-readable format covering at least the top-level dependencies.
That makes an SBOM more than an attachment to a compliance project. It is an input to vulnerability handling.
Evaluate whether the software can preserve relationships between:
- a specific product or release;
- the SBOM generated for that release;
- component identifiers and versions;
- vulnerability candidates affecting those components;
- exploitability or applicability analysis;
- remediation decisions and rationale;
- security updates or other treatment;
- disclosure records where relevant; and
- supporting evidence and review history.
The platform does not need to replace the scanner that discovers vulnerabilities. It does need a reliable way to retain the manufacturer's decision context after scanner results change.
Criterion 5: evidence history should survive change
Product-security evidence changes for legitimate reasons. A risk is reassessed, a component is upgraded, a vulnerability decision is revised or a test is repeated against a later build.
A compliance platform should not make that history disappear.
Prefer systems that distinguish correction from silent overwrite and can show:
- what was known at a specific point in time;
- which record replaced an earlier record;
- why a decision changed;
- who made or approved the change;
- the evidence available when the decision was made; and
- which later release inherited, replaced or invalidated that conclusion.
This is particularly important when preparing technical documentation or reconstructing the reasoning behind a release decision months or years later.
Criterion 6: release decisions need a defined evidence boundary
The CRA does not require manufacturers to use a software-based “release gate”. But engineering organisations still need a controlled way to determine whether required cybersecurity work is complete before placing a product on the market.
A useful tool should help teams distinguish:
- an open security task;
- a blocking product risk;
- an accepted or mitigated risk;
- missing verification evidence;
- incomplete technical documentation;
- unresolved vulnerability work; and
- a human release or conformity decision.
Be cautious with systems that automatically turn all green checklist items into a “CRA compliant” product state. The evidence can inform a decision; it does not remove the manufacturer's responsibility for the decision.
Criterion 7: integration boundaries should be clear
A CRA platform usually sits beside existing engineering systems rather than replacing them.
A practical architecture may keep:
- source code and version history in Git;
- work items in Jira or Azure Boards;
- build and test execution in CI/CD;
- signing and private keys in dedicated security infrastructure;
- vulnerability discovery in specialist scanners; and
- CRA workflow, evidence relationships, review history and lifecycle context in the compliance platform.
During procurement, ask what data crosses each boundary. A system should be able to use scoped metadata, hashes, evidence records and stable identifiers without requiring the compliance platform to become the build system or a source-code repository.
Also ask how automation authenticates and how records are tied to the intended product and release. Evidence imported by CI/CD is useful only if its provenance and scope remain clear.
Criterion 8: technical-documentation output must remain reviewable
Annex VII describes the technical documentation needed for conformity assessment. It includes product identification, design and development information, vulnerability-handling processes, cybersecurity risk assessment information, standards or technical specifications applied, test reports and related supporting material.
Software can help organise and generate documentation, but generated documents should remain reviewable against their source records.
Evaluate whether the tool can show:
- where each statement originated;
- which evidence supports it;
- which product/version it describes;
- what was generated automatically versus entered by a person;
- when the package was produced; and
- whether later evidence has superseded any part of it.
A polished PDF is not a substitute for traceability.
Criterion 9: reporting readiness is different from automatic reporting
From 11 September 2026, manufacturers have CRA reporting obligations for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
A compliance platform can help by keeping product identity, vulnerability decisions, timestamps, evidence and ownership organised so that the reporting workflow starts from controlled facts.
But procurement teams should separate reporting readiness from automatic regulatory submission. Ask whether the product supports preparation, review, approval and retained reporting context, and whether any external submission requires an explicit authorised action.
Criterion 10: exportability and retention matter
The Austrian Federal Chancellery's CRA guidance highlights that manufacturers must keep technical documentation and the EU declaration of conformity available for market-surveillance authorities for at least ten years after the product is placed on the market, or for a longer support period where applicable.
That creates a straightforward software-selection question: can you retrieve the necessary evidence independently of the user interface that created it?
Test:
- export of structured records and attachments;
- preservation of stable identifiers;
- version and revision history;
- timestamps and authorship;
- product/release relationships;
- document packages and their source references; and
- readable output suitable for review outside the platform.
Vendor lock-in is not only a commercial concern when the records must remain available long after an individual project ends.
Red flags during a CRA software demo
Treat the following as reasons to investigate further:
- the main output is a single organisation-wide compliance percentage;
- product and release versions cannot be separated;
- “compliant” can be selected without evidence or rationale;
- vulnerability decisions overwrite prior decisions;
- SBOMs are stored without reliable release context;
- uploaded evidence has no provenance, owner or review state;
- the system claims that completing its checklist establishes CRA conformity;
- technical documentation cannot be traced back to source records;
- CI/CD integration requires the platform to become the build or signing system without a clear need;
- exports lose relationships or history; or
- roadmap functionality is presented as currently available functionality.
None of these points alone proves that a product is unsuitable. They are prompts for due diligence because they can hide the lifecycle evidence problem the software is supposed to solve.
Questions to put into an RFP or proof of concept
A useful proof of concept should use one real product and one real release rather than a generic demonstration tenant.
Ask the vendor to show:
- How is a product, variant and release represented?
- How is a CRA requirement linked to implementation and evidence?
- Can the same requirement have different evidence for different releases?
- How is the cybersecurity risk assessment versioned and reviewed?
- How are SBOMs scoped to exact releases?
- How are vulnerability decisions revised without losing history?
- Can evidence from CI/CD retain provenance and product scope?
- How are release blockers separated from final human decisions?
- How is technical documentation assembled from controlled records?
- How can the complete evidence package be exported?
- Which functions exist now, which are MVP scope and which are roadmap?
- Which actions require user confirmation?
- Does the platform ever claim to determine CRA conformity? If so, what exactly does that statement mean?
The best evaluation is evidence-based: require the vendor to demonstrate each answer against the same sample product lifecycle.
Where AA-sec fits in this evaluation
AA-sec is a B2B cyber-resilience and CRA-readiness platform for manufacturers and engineering organisations, designed around traceability between requirements, security evidence, SBOM, vulnerability work, assessments, release decisions and exact product or lifecycle context. The MVP scope includes release blockers, release lifecycle workflows, evidence packages, assessment/readiness workflows and direct REST API integration for CI/CD evidence ingestion. AA-sec is intended to complement existing engineering and delivery systems; it does not determine CRA conformity or make engineering decisions automatically without user confirmation.
Key takeaway
Choose CRA compliance software by the quality of the lifecycle record it helps you maintain.
A checklist can help organise work, but the durable value is the ability to show what requirement applied, what the team did, what evidence supports the result, which product and release were affected, who made the decision and how that conclusion changed over time.
That is the standard a proof of concept should test. The tool should make the manufacturer's evidence easier to structure, review and retrieve without pretending that software can replace the manufacturer, engineering judgement or the applicable conformity-assessment process.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Commission publishes new guidance to support timely Cyber Resilience Act implementation — European Commission
- Cyber Resilience Act — European Commission
- Cyber Resilience Act - Reporting obligations — European Commission
- Fragen und Antworten zur Cyberresilienz-Verordnung — Austrian Federal Chancellery