What can CRA compliance software actually automate?
CRA compliance software can automate repeatable evidence work and assist analysis. It cannot make a product compliant on its own. Manufacturers still need to make and document accountable decisions, implement security measures and complete the applicable conformity and reporting procedures.
Automate the task. Keep the decision accountable.
Automatable means repeatable on supported, sufficiently complete inputs. Assistable means a proposal for review. Neither means the manufacturer can delegate its legal responsibility to software.
| Task | What software can do | Boundary and responsibility |
|---|---|---|
| Automatable: repeatable work on defined inputs | ||
| Repository collection | Collect supported source evidence and record its origin, version and hash. | Collection is bounded. Repositories do not contain all organisational, hardware or operational evidence. |
| SBOM ingestion | Read supported SBOM formats and attach the supplied inventory to a release. | Structural readability does not establish completeness or validate the manufacturer's SBOM. |
| Dependency correlation | Match exact, identifiable component versions to supported vulnerability feeds. | Unmatched components and feed outages remain visible unknowns. A match is not a product affectedness decision. |
| Release comparisons | Compare recorded baselines and show changed evidence, components and findings. | A person reviews the significance. In ConformOps, named release updates require Continuous access. |
| Evidence indexing | Index sanitized evidence for retrieval with source provenance. | Retrieval relevance is not proof that a requirement is satisfied. |
| Legal-reference attachment | Attach versioned references from a maintained ruleset. | A citation alone does not prove applicability or legal correctness; law and non-binding guidance must remain distinct. |
| Technical-document drafting | Assemble structured working records from available evidence and recorded facts. | People must supply missing information and review accuracy, adequacy and completeness. |
| Deadline calculation | Calculate reporting clocks from the recorded case type and awareness inputs. | People determine the relevant facts and trigger. Incorrect inputs produce incorrect deadlines. |
| History and audit records | Record versions, actions, evidence links and decisions made in the system. | Recorded history does not prove that unrecorded work happened or that a control works. |
| Document regeneration | Produce a new working document for a changed evidence baseline. | A new draft does not inherit a signature or silently replace an approved historical document. |
| Assistable: proposals that need review | ||
| Evidence-to-requirement proposal | Suggest potentially relevant evidence and explain a proposed mapping. | A reviewer checks relevance and sufficiency. AI cannot approve a gap or obligation. |
| Risk-analysis preparation | Organise evidence, candidate scenarios and missing information for assessment. | Qualified people analyse the product context and assess and accept risks; missing data is not a low-risk score. |
| Affectedness analysis | Bring component matches, release context and exploitation intelligence together. | A person investigates whether the vulnerability affects this product. A KEV listing alone does not settle that question. |
| Classification support | Structure product facts and flag potentially relevant category criteria. | An accountable person approves classification, with specialist advice where needed. |
| Report drafting | Help organise facts and prepare text for review. | The accountable reporter verifies the content. ConformOps case records are not submission to a reporting platform. |
| Human or legal responsibility: software records the outcome | ||
| Final scope decision | Preserve product facts and the rationale. | The manufacturer determines scope and market role with qualified advice where needed. |
| Classification approval | Record the accountable decision against the relevant inputs. | An authorised person approves the proposed category. |
| Risk acceptance | Keep evidence and decision history together. | The manufacturer evaluates residual risk and required measures. Acceptance cannot waive a legal requirement. |
| Affectedness decision | Record status, evidence, author and justification. | An accountable person decides affected, not affected, fixed or still under investigation. |
| Article 14 trigger decision | Present facts and preserve the reporting review. | The manufacturer determines whether an actively exploited vulnerability or severe incident meets the reporting conditions. A CVE match alone is insufficient. |
| Report submission | Support preparation, clocks and records of filing. | The responsible reporter files through the applicable reporting channel. ConformOps does not submit reports. |
| Conformity route | Apply deterministic route logic to recorded facts and show required gates. | The manufacturer confirms the applicable procedure and completes it, involving an external body where required. |
| Declaration approval and signature | Generate an Annex V structured EU Declaration of Conformity draft. | The responsible signatory approves and signs only after the applicable requirements and procedure have been fulfilled. |
| CE marking | Track readiness records and outstanding steps. | The manufacturer is responsible for affixing the marking under the applicable rules. A generated file is not permission to mark. |
| Notified-body work | Organise engagement records, findings and external evidence. | Where the route requires a notified body, that body performs its assessment. Software or a general consultant cannot substitute for it. |
Connect CI/CD evidence, a release gate and signed webhooks with the Continuous CLI and API.
Can CRA compliance be automated?
Parts of the work can. Evidence collection, comparisons and record generation can repeat against defined inputs. Compliance also depends on product design, engineering, vulnerability handling, organisational processes and accountable decisions. This matrix describes task boundaries, not a claim that every software product implements every task.
Can AI make my software CRA compliant?
No. AI can propose explanations, mappings or draft text, but those outputs may be wrong or incomplete. In ConformOps, optional AI proposals do not approve risks, satisfy obligations, select final legal routes or sign declarations. The deterministic engine and recorded human decisions remain authoritative.
Does CRA software replace a consultant?
It can take on recurring evidence administration. It does not replace specialist judgment, organisational work or independent assessment. A team with sufficient expertise may do much of the work internally; another may need a consultant to establish the evidence model and review significant changes.
Can software generate an EU Declaration of Conformity?
Software can generate a draft. ConformOps produces an Annex V structured working declaration with visible missing information and approval gates. Generating it is different from drawing up and signing the manufacturer's final declaration after the applicable conformity procedure. Article 28 and Annex V govern the declaration; Article 32 governs assessment procedures.
What ConformOps covers today
ConformOps collects supported repository evidence, accepts CycloneDX JSON or SPDX JSON SBOMs, correlates eligible dependencies with OSV, indexes sanitized evidence and produces controlled working documents. Ongoing source updates, named releases, daily OSV monitoring, Article 14 case operations and the scoped CI/CD CLI/API with engineering release gates and signed webhooks require Continuous coverage. It does not fix code, conduct penetration tests, validate a supplied SBOM, file regulatory reports or perform notified-body assessment.
The duties belong to the manufacturer.
Regulation (EU) 2024/2847 is binding law. This page explains task boundaries; it is not a legal opinion on your product.
- Article 13(2), (3) and (12): manufacturer risk assessment, documentation and conformity obligations.
- Article 14: reporting of actively exploited vulnerabilities and severe incidents.
- Articles 28, 30 and 32; Annexes V and VII: declaration, CE marking, assessment procedures and technical documentation.
Reporting clocks depend on the event and recorded awareness facts. Read the Article 14 reporting guide for the distinct deadlines.