Cyber Resilience Act. Technically implemented.
Most tools assess your HEAD. The 3.9 branch you still maintain is not HEAD. Farion assesses every new vulnerability against all the release branches and tags you still support, and keeps the justification and the fix on the record per branch.
The CRA also covers device and machinery manufacturers.
Do you place products with digital elements on the EU market under your own brand? CRA manufacturer obligations may apply. The scope generally covers software and hardware whose intended or foreseeable use includes a direct or indirect data connection to devices or networks. An internet connection is not required.
Outsourcing development does not remove manufacturer obligations when you offer the product under your own name or brand. Exemptions and special rules apply to certain products and forms of supply.
Does this include your product?
Software products
Apps, desktop software and on-premises applications.
Embedded systems
Control modules and devices with embedded firmware.
IoT products
Connected sensors, gateways and smart-home devices.
Machinery and industrial equipment
Connected controls and automation technology.
Network and security devices
Routers, switches and firewalls.
A versioned SBOM as the foundation of your CRA process.
A software bill of materials (SBOM) records the software components of a product version. Ongoing vulnerability handling requires this inventory for older versions you still support.
Farion connects the inventory to applications, services and analyzed versions, so you can trace which library version is included in each product version.
Capture components and dependencies
Farion creates SBOMs with direct and transitive dependencies. Container, virtual-machine and filesystem analyses add the application and operating-system packages they detect.
Distinguish supported versions
Inventories stay linked to applications, services, branches, tags and commits, including releases supported in parallel.
Detect new vulnerabilities without a new release
New advisories and vulnerability information feed into reassessment of the recorded inventory without requiring a new build.
Export SBOMs for documentation and exchange
Export a version’s component inventory for technical documentation, internal reviews and customer requests, retaining the link to that version.
From affected component to documented correction.
Use the recorded software inventory as the basis for ongoing security assessment, remediation and evidence.
Exploited in the world is not affected in your code.
Two signals that are easily confused. Whether a vulnerability is demonstrably being exploited is what the threat context tells you: CISA KEV, exploit maturity, EPSS. Whether it touches your branch at all is something only the analysis of your code can tell you — reachability and data flow, for entry points reachable over HTTP. Only together do they produce the justified statement the CRA asks for: affected or not, and why. The no stays on the finding too, with its justification and the code that supports it, and can be passed on as VEX.
Drive corrections across the branches you maintain.
Owners, due dates, and decisions hang off the individual branch rather than one global ticket. A fix on main says nothing about release/3.9: each carries its own remediation state, and open or overdue work stays visible per branch.
Evidence your decisions and measures for audits.
Farion links the component inventory of a branch to assessments, ownership, remediation history, and the corrections applied. The records are produced while the work happens and export coherently as SBOM, VEX, SARIF, a PDF report, or through the API.
Reach for facts you already have.
The 24-hour deadline is only survivable if you know, at hour zero, which of your maintained branches contain the component — and whether the vulnerable code is reachable there at all. On the Commission's reading, a vulnerability in a third-party component is only reportable if it can actually be exploited in your product. Those are the two answers Farion supplies; the notification itself stays with you.
Which requirements apply when?
Since 11 September 2026
Reporting obligations
Reporting obligations under Article 14 — including for products placed on the market before 11 December 2027 (Art. 69(3)).
From 11 December 2027
General application
Product security, vulnerability handling, and conformity assessment become generally applicable (Art. 71(2)).
Transitional rules apply to products placed on the market earlier. Reporting obligations also cover those products within the scope of the CRA.
Start with one repository. Establish the process for your portfolio.
Connect a repository and have one maintained release branch analyzed. For a company-wide rollout we work through which branches and tags represent your supported product versions, and how ownership and due dates fit into your release workflow.
A note on scope
Farion supports the technical implementation of software supply chain security and vulnerability handling within the CRA. Full CRA conformity covers further requirements, among them secure product design, update distribution, user information, and the required conformity assessment. Responsibility for meeting the manufacturer’s obligations remains with you. This text is not legal advice.