Introduction

Pharus handles CRA Article 14 for product companies: it finds exploited vulnerabilities in your SBOMs, starts the clocks and prepares every report.

Pharus is vulnerability handling for companies that make products with digital elements and sell them in the EU. It covers the reporting duties in Article 14 of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), and the everyday vulnerability work the CRA asks for between incidents. It is built in Norway, for Nordic manufacturers, in Norwegian and English.

Article 14 gives you 24 hours from the moment you become aware of an actively exploited vulnerability in your product to send an early warning. Pharus makes that deadline reachable: it watches your products, opens the incident, pages whoever is on call, names the authority the report goes to, and prepares the text for ENISA’s Single Reporting Platform.

How it works

1. Your SBOMs come in

   Your CI pipeline, Dependency-Track or a manual upload sends a CycloneDX or SPDX SBOM for each product family. Pharus matches every component against OSV.dev, and flags the ones that are known to be exploited in CISA KEV and ENISA’s EUVD. See SBOMs and vulnerabilities.

2. An incident opens with its clocks

   A new exploited match opens an incident on its own, and the CRA clocks start from the moment of awareness: 24 hours for the early warning, 72 hours for the notification, then the final report. You can also declare an incident by hand, or from a vulnerability report. See incidents and clocks.

3. You decide, on the record

   Is it reportable: was the vulnerability actively exploited in your product? The rationale, evidence and approvals go into an append-only record, which is what a regulator will ask for, and every correction to the awareness time is logged. See decision record and audit trail.

4. Pharus routes and prepares the reports

   Pharus names the EU CSIRT your report goes to under Art. 14(7), and prepares a paste pack for every stage of the SRP form. Where GDPR, digitalsikkerhetsloven or DORA also apply, it runs their deadlines and drafts the notices for Datatilsynet, NSM and Finanstilsynet. See routing and SRP paste pack.

After the filing, Pharus helps you inform users, publish a CSAF advisory and report the flaw upstream to the component’s maintainers.

Between incidents

Most weeks nothing is on fire. Pharus still does the work the CRA asks for in between:

Disclosure page and inbox

A public report form, a hosted disclosure policy, security.txt and an inbox with a triage log. Included on Free.

Security advisories

CSAF 2.0 advisories with VEX statuses, on your public advisory page and in a machine-readable feed.

Weekly exposure digest

New exploited matches across every product family, every Monday morning.

Support periods

An end date per release line, and a reminder before it runs out.

On-call paging

A rota that covers weekends, SMS paging and escalation when nobody acknowledges.

Board report and drills

Quarterly evidence that vulnerability handling works, and an annual tabletop exercise.

What Pharus doesn’t do

• File the report for you. ENISA’s Single Reporting Platform has no API. Pharus fills in the SRP fields it has the answer for so you can paste them in, and records what you filed and when.
• Give legal advice. Pharus applies the rules as the regulations write them and shows its reasoning, but the determination is yours. For the background, read the CRA playbook.
• Replace your SBOM tooling. Pharus reads SBOMs from your pipeline or from Dependency-Track and adds the clocks, routing and records on top.

Get started

Quickstart

From sign-up to your first matched SBOM in about ten minutes.

Key concepts

Workspaces, product families, awareness, clocks and the words Pharus uses for them.

Plans and features

What Free, Starter, Core and Plus include, and how the trial works.

API reference

Send SBOMs from CI, connect Dependency-Track and receive signed webhooks.