On this page
- Describe the product's core functionality before selecting a proposed category.
- Keep scope, classification and conformity-route facts distinguishable.
- An SBOM supports component work; it cannot approve a legal category.
- Changed product facts require renewed review, not an invisible update to the old conclusion.
Why a shared record helps
Consider a collaboration application that includes authentication and an encrypted connection. Its dependencies may look similar to those of a security product, but that does not settle its CRA category. The team needs a description of what the application is supplied to do, its intended users and its main functions.
The technical descriptions in Implementing Regulation (EU) 2025/2392 help interpret the important and critical product categories. Keep the relevant description next to your product facts and supporting architecture material. The presence of an operating system or cryptographic dependency inside a product is not, by itself, a classification of the containing product.
Record the facts that drive the decision
In ConformOps, product intake records intended purpose, distribution, market role, proposed category, support period and conformity-route facts. Use precise descriptions: a customer-installed endpoint agent is more useful than a generic SaaS label. Identify any remote processing necessary for product functions and document the commercial supply arrangement separately.
A proposed answer is still a proposal. An Owner or Admin must make the accountable approval decision through the approval workflow. Editing product facts does not itself approve them. This separates the person supplying information from the act of accepting its legal significance.
Evaluate the route supported by those facts
ConformOps derives a proposed route from the recorded category and standards, common-specification or certification facts. It identifies missing information and external-assessment work where applicable. Do not interpret a populated route field as proof that a standard was fully applied or that a certificate covers the assessed release.
The Commission's conformity-assessment explanation distinguishes default products from categories with stricter procedures. Important Class I is not a universal requirement for third-party assessment; the actual legal conditions and applicable specifications matter. Important Class II and critical products must not be collapsed into the same label. Use qualified review where category or route remains uncertain.
Attach component evidence without changing its meaning
Supply the release's CycloneDX JSON or SPDX JSON SBOM and inspect its provenance and quality. ConformOps can connect component and vulnerability information to the assessment record. That makes it easier to explain which inventory supported an investigation, but does not turn the inventory into proof of the classification.
For example, a newly introduced authentication service may require two parallel tasks. Engineering reviews the shipped component and its vulnerabilities. The product reviewer considers whether a changed function affects scope or category. Completing the component task does not automatically complete the legal task.
Carry the decision into controlled documentation
Technical documentation should let a reviewer connect the product description, selected assessment route and security evidence. In ConformOps, approval decisions and artifacts remain associated with the assessment record. Generated working documentation must retain its limits, missing facts and approval state.
When a material input changes, inspect the new review requirements. Do not assume an earlier approval still covers a different product description or assessment. External engagement records can document assessor or certification work, but recording progress does not impersonate the manufacturer's accountable acceptance.
Use ConformOps as the record, with expertise around it
The useful consolidation is one place to trace product facts, evidence and decisions. It does not mean every security test, specialist opinion or authority interaction happens inside the platform. Keep the actual supporting material and identify its author, scope and version.
For a purchasing decision, ask to change one classification-relevant fact, inspect the proposed route and review the resulting approval state. Then open the SBOM and explain its separate role. The tool evaluation checklist provides a way to record whether that demonstration meets your needs.
Frequently asked questions
Can ConformOps automatically approve a CRA classification?
No. It supports recorded product facts and proposed route logic. Accountable human approval remains a separate, permission-controlled decision.
Does an SBOM determine the product's CRA class?
No. The product's core functionality and applicable category descriptions drive classification. Inventory evidence can inform the review but cannot settle it by itself.
Is ConformOps the only system the team needs?
It can hold the connected evidence and decision record. Security tests, build systems, specialist advice and any required external conformity work remain separate responsibilities.