How to Choose Cyber Resilience Act Compliance Software
Start with the job you need done. Then ask for the evidence.
Choose Cyber Resilience Act compliance software by matching your missing workflow to the tool's demonstrated coverage. Evaluate the inputs it actually reads, the evidence it preserves for each release, the decisions it leaves to people and what happens when something fails. Buy against a representative product demonstration, not a feature count.
First identify which job you're buying
“CRA software” covers several different jobs. A team with mature security tooling and scattered documentation needs a different purchase from a team that cannot identify what ships in its firmware. Use the six-category model from our CRA software comparison hub to name your bottleneck.
These are purchasing categories, not six legal requirements or a requirement to buy six products. One tool may cover several jobs; a specialist may be the right choice for just one.
Regulatory planning
Ask for a scoped product assessment, cited legal basis, accountable owner and sequence of work. A questionnaire alone does not test a product.
Product and release security
Ask for engineering results: security tests, secure configuration checks and release controls. A requirement mapped to a policy does not demonstrate that a control works.
SBOM and vulnerability management
Ask for the shipped inventory, matching coverage, intelligence health and recorded triage. A clean scan is only meaningful within its observed scope.
Evidence collection
Ask to follow a finding back to its source and release. A document upload count does not tell you whether the material supports a requirement.
Technical documentation
Ask for an export with evidence references, missing sections and approval state. A populated template can still be an incomplete technical file.
Ongoing compliance operations
Ask to run a release change, an intelligence outage and a reporting drill. A one-time assessment does not establish who handles the next event.
15 questions to ask a CRA software vendor
For each answer, record whether you saw it demonstrated, received a document, heard a roadmap promise or found it outside scope. An honest boundary is useful. An untested promise is still an open procurement question.
What source material do you actually inspect?
Ask for a precise input boundary: repository text, lockfiles, build outputs, firmware, test results, supplier documents or questionnaires. Reading one of these does not imply reading the others. File limits, excluded directories and unsupported languages should be visible in the assessment.
Use a representative release with a nested manifest and an unsupported file. Ask the vendor to show what was read, skipped or unreadable, and where the report names those limits.
Do you execute my source code?
Read-only credentials describe access permissions, not execution behavior. Establish whether the service installs dependencies, runs build scripts or hooks, launches binaries, or only reads files. Execution can be useful for security testing, but it changes the isolation, network and credential requirements you must evaluate.
Request the data-flow and execution diagram, including worker isolation, outbound access, secret handling, retention and any AI processors. Match the explanation to the actual import workflow.
Can I see the evidence behind each finding?
A defensible finding identifies the requirement, supporting material and reasoning that connects them. Look for a stable document or source locator, the assessed version and the collector or rule version. Keep observed facts, inferred mappings and human judgments distinguishable.
Pick a finding the vendor did not select. Follow it to the exact supporting passage and its legal reference, then inspect a finding with missing or contradictory evidence.
Is evidence release-specific?
A product dashboard can silently mix evidence from different releases. Ask whether the source snapshot, inventory, findings, decisions and exports describe the same identifiable release, and what happens to the previous baseline when new input arrives or a repeat assessment fails.
Assess release A, change the source for release B, then interrupt the new assessment. Reopen A and check that its evidence and decisions remain readable without being presented as current for B.
Can supplied SBOMs override derived inventories?
A supplier or build-generated software bill of materials (SBOM) may represent shipped components more accurately than repository manifests. Ask which inventory takes precedence, whether both origins remain inspectable and how disagreements are shown. File presence, structural readability and completeness are separate properties.
Supply an SBOM that omits a component found in a lockfile. Ask which inventory is used for matching, where the discrepancy appears and whether the original assessment still points to its original SBOM.
Which formats do you actually parse?
An upload button is not a parser. Ask for supported format versions and encodings, such as CycloneDX JSON versus XML or SPDX JSON versus tag-value, plus supported dependency files and ecosystems. A version range should not become an invented exact shipped version.
Try your real formats, a malformed document and a manifest containing only ranges. Check for an explicit refusal or partial result, unresolved versions and a clear account of unobserved components.
What happens when a vulnerability feed is unavailable?
A failed lookup must remain distinguishable from a successful lookup with no matches. Ask for last-success time, feed freshness, matching coverage and retry behavior. An incomplete check should not close earlier findings merely because an advisory was absent from the response.
Have the vendor simulate an outage after a successful check with a known match. Inspect both the dashboard and export for the retained finding, the failure and the age of the last usable intelligence. Ask the overview to distinguish evidence, human approvals, intelligence health, reporting operations and paid access, each with its own scope and next action.
Do you calculate exploitability or require human affectedness?
Package matching, severity, reachability analysis, exploitation intelligence and product affectedness answer different questions. Ask what an automated result actually establishes and what evidence a reviewer needs to decide whether this release is affected. Neither a severity score nor an exploitation listing alone proves exploitation of your product.
Record a justified not-affected decision for one release, then change the component version. Check the decision history, whether reassessment is needed and whether Article 14 review remains a separate decision.
How do you separate a compliance gap from cybersecurity risk?
Missing documentation is missing evidence. It does not, by itself, establish a threat scenario, likelihood or impact. Ask how the tool records unresolved requirements separately from product security risks, while linking them where an actual control weakness supports both.
Remove a support-policy document and add a genuine security finding. Inspect whether the first becomes an evidence gap and the second receives contextual risk assessment rather than an automatic compliance percentage.
Which decisions require humans?
Request the approval model for scope, classification, conformity route, risk acceptance, reporting outcomes and declaration sign-off. Identify who can propose, who can approve and what changed evidence invalidates. AI suggestions should retain their proposal status until an authorized person makes the accountable decision.
Use an ordinary team-member account to attempt an approval, then change approved input. Ask to see the refusal, the responsible approver and the original decision alongside the new review requirement.
How does Article 14 awareness get recorded?
Ask for separate records of signal receipt, the manufacturer's awareness, the reporting trigger, rationale and responsible person. A scanner timestamp is not automatically the legal awareness timestamp. Conversely, delaying entry in a tool must not reset a clock that already started when the manufacturer became aware.
Run a drill with awareness earlier than data entry. Check that the 24-hour and 72-hour deadlines use awareness, that corrections retain history and that actively exploited vulnerabilities and severe incidents follow their different final-report rules.
Reference: CRA Articles 14 and 16; Commission reporting explanation. See the reporting deadlines and triggers.
Does the product actually submit reports?
A case register, countdown or prepared notification does not establish delivery to an authority. Ask who submits, through which channel, with whose authorization, and how receipt and failed delivery are recorded. If the product only prepares material, assign the external submission step to a named person.
Walk through a reporting drill without sending a real notification. Locate the handoff, the place for the authority's receipt and the escalation procedure if submission fails. Check that draft and submitted states cannot be confused.
Reference: CRA Articles 14 and 16; Commission reporting explanation. See the reporting deadlines and triggers.
What exactly does “technical documentation generated” mean?
Request the actual output list and its scope: populated templates, evidence registers, test reports, user instructions or an assembled technical file. Ask how the export maps to Annex VII, where absent material is marked and how draft status differs from manufacturer approval. A generated file is not a conformity assessment.
Export a deliberately incomplete product. Open the files and locate missing inputs, evidence references, release identity and approval state. Ask what remains for engineering, the manufacturer and any applicable external assessor.
Reference: CRA Article 31 and Annex VII. See technical documentation guidance.
Can I reproduce a decision from nine months ago?
Ask whether you can reconstruct what was known, which rule and tool versions applied, who decided and which artifact they reviewed. Re-running today's engine against today's feeds is not historical reconstruction. If a vendor promises identical recomputation, ask how it retains dependencies and handles nondeterministic AI output.
Open an older decision after a ruleset or intelligence update. Export its original inputs, recorded reasoning, approval history and artifact hashes. Confirm retention, export access after cancellation and the limits of deletion and backup policies in the contract.
Can an external reviewer inspect provenance?
A shared status page may expose totals without evidence. Establish whether the reviewer can inspect legal citations, source locators, excerpts, decisions and release identity, or needs a separate controlled export. Review access must also respect confidential source material and the permissions granted by its owner.
Open a share as an external reviewer, trace one conclusion and note anything unavailable. Revoke access and test again. Inspect expiry, access logging and exactly which data leaves the workspace.
One release. One change. One failure.
Use the same representative, authorized sample with every shortlisted vendor. Bring the source or build inventory you actually maintain, a supplied SBOM if relevant, one known finding and one missing document.
- Establish the baseline. Follow a requirement from input to finding, human decision and exported artifact. Record anything you could not verify.
- Change the release. Replace a dependency or evidence document. Check what becomes stale, what requires review and whether the previous record remains intact.
- Introduce a failure. Simulate unavailable intelligence or a failed assessment. Check that unknown coverage stays visible and prior evidence remains usable.
- Rehearse the handoff. Give an external reviewer the permitted output and run a reporting drill through to the submission handoff, without filing a real report.
Keep a short procurement record: required job, observed result, evidence link, limitation, person responsible for the remaining work and contract commitment. Compare total operating cost, including supported products, releases, monitoring, reviewer access, exports, onboarding and exit. Do not turn every “yes” into an equally weighted score.
The legal baseline, separate from buying advice
The evaluation method above is ConformOps' editorial advice. The CRA does not prescribe this checklist or certify a software purchase as compliance.
- Regulation (EU) 2024/2847 is the binding text. Article 13 addresses manufacturer obligations; Articles 14 and 16 address reporting; Article 31 and Annex VII address technical documentation; Article 32 addresses conformity assessment.
- The Commission's reporting explanation is non-binding guidance. Reporting obligations apply from 11 September 2026. Early warning and notification are due within 24 and 72 hours of awareness. For actively exploited vulnerabilities, the final report is due within 14 days after a corrective or mitigating measure is available; for severe incidents, within one month after the incident notification.
Software supports the manufacturer's work. It does not replace engineering verification, accountable legal and conformity decisions or any required external assessment. For ConformOps' own boundaries, read the factual product reference and trust documentation.
Which type of tool do you actually need?
You do not yet know your scope or route
Start with regulatory planning and qualified advice for unresolved legal questions. Buy a tool once the product boundary, market role and responsible team are clear.
You need to find and fix security weaknesses
Prioritize product security testing and engineering controls. For firmware or complex native builds, demonstrate coverage of shipped binaries and build dependencies before buying a repository-oriented workflow.
You cannot reliably name or monitor shipped components
Prioritize SBOM and vulnerability management. Evaluate supplier inventories, ecosystem depth, affectedness workflow and feed health using your own release.
Your security tools work, but reviewers cannot follow the evidence
Prioritize evidence collection and release provenance. Preserve the specialist tools you already trust and test the handoff from their results to a requirement and decision.
Your evidence exists, but the technical file is fragmented
Prioritize documentation assembly, controlled exports and accountable review. Verify coverage of required material before paying for the speed of template generation.
You ship frequently or maintain many supported products
Prioritize ongoing operations: release changes, support tracking, vulnerability triage, reporting drills, ownership and historical access. Test recurring work and its total cost, not just initial onboarding.
A small, stable portfolio may be manageable with specialist security tools, controlled documents and a disciplined manual register. Frequent releases, repeated evidence requests and unclear handoffs make workflow software more valuable. Choose the combination your team can operate and explain, with a named owner for every gap between tools.
The right purchase closes your missing workflow and makes its limits visible. Start there.
Compare the approaches