30 min with a CRA specialist - your classification confirmed against real specs, your open questions closed. Free, no obligation.Rulebook v0.5.1Full compliance 11 Dec 2027
Worked example · Security software
No hardware anywhere - and still Important Class I
A pure-software SaaS vendor with desktop, mobile and browser clients
Worked example - a product archetype run through the CRASPACE rulebook. Not a client engagement, and not a conformity assessment.
The verdict
CRA scope
In scope
Class
Important - Class I
Basis
Annex III, Part I
Conformity route
Self-assessment only if harmonised standards are applied; otherwise a notified body
Descriptor matched: Password manager (and, separately, a browser component)
The single most common misreading of the CRA is that it is about devices. A product with digital elements includes software placed on the EU market on its own. There is no hardware exemption and no hardware requirement.
"Password manager" is a named Annex III Part I descriptor - one of the most explicit in the whole annex. The class follows directly.
The browser extension matches the `browser` descriptor independently. Two products, two classifications, one technical file each.
The pure-SaaS boundary is the genuinely hard part, and the tool says so rather than guessing: a remote service consumed over the network can fall outside, while the software the customer installs does not. The line runs through the product, not around the company.
What follows from it
✓Annex I essential requirements applied to software: secure defaults, no known exploitable vulnerabilities at release, protection of the data the product processes
✓An SBOM that reaches the dependency tree, not just the top-level packages
✓Coordinated vulnerability disclosure - for a security product this is table stakes, and its absence is conspicuous
✓Security updates across the support period, and a stated support end date per major version
✓Reporting readiness for the 24h/72h duties that begin 11 September 2026
The trap on this one
Software vendors routinely scope themselves out on the grounds that they ship no hardware. That reading has no basis in the regulation, and for a security product the class is Important rather than Default - a strictly higher bar than the appliance maker two examples up.
The questions this leaves open
A public-evidence scan cannot answer these. They are what a consultation is for, and they are deliberately questions rather than instructions.
Which components are placed on the market as products, and which are delivered purely as a remote service?
Does the SBOM cover transitive dependencies, and is it regenerated per release rather than maintained by hand?
Is there a documented support period per major version, or an implicit "latest version only" policy that has never been written down?
The realistic next step
Software-only vendors are the case where a consultation earns its keep before any testing: the product/service boundary decides the size of the obligation, and it is a scoping question, not a lab question.
This is an archetype. Yours is not. Run the check against your own company and get the same reasoning applied to the products you actually ship, each with a source you can open.