The terms come in the order you meet them: the rules, who you report to, the vulnerabilities, the clocks, the day-to-day work and what comes in 2027. Each one says what it is, why it matters to you, and what Pharus does about it.
Want it all in context? The CRA guide covers the whole regulation, and the CRA playbook walks through the deadlines, the recipients and what each notification must contain.
The rules
- CRACyber Resilience Act, Regulation (EU) 2024/2847
The EU law that sets cybersecurity requirements for products with digital elements: hardware and software sold in the EU.
Why it matters to you: If you sell such products in the EU, its reporting duties have applied since 11 September 2026, wherever you are based. The rest of the law follows on 11 December 2027.
How Pharus helps: Pharus is built for the CRA’s reporting duties: the clocks, the decision, the recipient and the text you file.
Read the CRA playbook- Article 14The CRA’s reporting duty
The part of the CRA that says what a manufacturer must report, to whom and how fast: actively exploited vulnerabilities and severe incidents.
Why it matters to you: It is the part that applies already, and its deadlines are counted in hours, weekends and holidays included.
How Pharus helps: Every incident in Pharus runs on Article 14’s clocks, from the early warning to the final report.
- Product with digital elements
The CRA’s name for what it covers: a hardware or software product that connects to a device or a network, including the remote data processing it needs to work.
Why it matters to you: Smart devices, machines with software, apps and firmware are all covered. Pure SaaS with no product placed on the market mostly isn’t; it falls under NIS2.
- Manufacturer
Whoever designs or makes a product, or has it made, and sells it under their own name or brand.
Why it matters to you: The CRA’s duties are the manufacturer’s, even when parts of the product come from suppliers or open-source projects.
- NIS2Network and Information Security Directive 2
An EU directive with security and reporting duties for businesses that run important services, such as energy, transport, health and digital infrastructure.
Why it matters to you: NIS2 is about the service you run; the CRA is about the product you sell. A company can be covered by both. NIS2 is not yet part of the EEA Agreement or Norwegian law.
How Pharus helps: Pharus shows NIS2 as “tracked” until it applies in Norway.
- DigitalsikkerhetslovenThe Norwegian Digital Security Act
Norway’s implementation of the first NIS directive, in force since 1 October 2025.
Why it matters to you: If you provide a service it covers, incidents that significantly affect that service must be reported to NSM, within 24 hours for essential services.
How Pharus helps: When it applies, Pharus drafts the notice to NSM in Norwegian, from the same incident.
- REDRadio Equipment Directive
The EU directive for radio equipment. Since 1 August 2025 it has included cybersecurity requirements for internet-connected radio equipment, and for toys, childcare products and wearables.
Why it matters to you: They are already enforced in Norway, by Nkom. The harmonised standards are EN 18031-1, -2 and -3. From 11 December 2027 the CRA takes over.
Read about reporting from Norway- DORADigital Operational Resilience Act
The EU’s rules for digital resilience in the financial sector: banks, insurers and other financial entities.
Why it matters to you: If you are a financial entity supervised by Finanstilsynet, a security event can call for a DORA report alongside the CRA.
How Pharus helps: Pharus can assess the event under DORA and draft the notice to Finanstilsynet, in English, which it prefers.
Who you report to
- ENISAThe EU Agency for Cybersecurity
The EU’s cybersecurity agency. Under the CRA it runs the Single Reporting Platform and receives every notification.
Why it matters to you: Your CRA notifications reach ENISA at the same time as the CSIRT that handles them.
- SRPSingle Reporting Platform
ENISA’s website where CRA notifications are filed. It is English-only and has no API, so every notification is typed or pasted in by hand.
Why it matters to you: Filing is a form with a 24-hour deadline. You need people with access, through EU Login with two-factor sign-in, before anything happens.
How Pharus helps: Pharus fills in the SRP form’s fields from the incident, in English, ready to copy and paste. You record the receipt in Pharus.
- CSIRTComputer Security Incident Response Team
A national team that handles security incidents. Every EU member state has designated one CSIRT as coordinator for CRA reports.
Why it matters to you: Your CRA report goes to one specific CSIRT, and which one depends on your route under Article 14(7).
How Pharus helps: Pharus finds the right CSIRT for each product family.
See the CSIRT in every EU member state- Reporting routeArticle 14(7)
The rule that decides which EU member state’s CSIRT receives your reports when the manufacturer has no main establishment in the EU: where your authorised representative is, else your importer, else your distributor, else where most of your users are.
Why it matters to you: For a Norwegian manufacturer this rule decides where reports go. The answer changes when you switch importer or sign a new distributor.
How Pharus helps: Pharus works out the route for each product family and names the recipient.
Find your route- NkomNorwegian Communications Authority
Norway’s authority for electronic communications. The government has announced that Nkom will supervise the CRA in Norway.
Why it matters to you: Nkom can’t receive CRA reports until the CRA is part of the EEA Agreement and Norwegian law, with 11 December 2027 as the aim. Until then reports go to an EU CSIRT. Nkom already enforces the cybersecurity requirements for radio equipment.
How Pharus helps: When a date is decided, Pharus routes Norwegian companies to Nkom from that day.
- NSMNorwegian National Security Authority
Norway’s national security authority. It receives incident notices under digitalsikkerhetsloven.
Why it matters to you: Notices to NSM are written in Norwegian, with their own deadline, alongside any CRA report.
How Pharus helps: Pharus drafts the notice in Norwegian, from the same incident.
- DatatilsynetNorwegian Data Protection Authority
Norway’s data protection authority, which receives notices of personal data breaches under the GDPR.
Why it matters to you: If a security event exposes personal data, Datatilsynet must be notified within 72 hours, alongside any CRA report.
How Pharus helps: Pharus drafts the notice in Norwegian, from the same incident.
Vulnerabilities and incidents
- Vulnerability
A weakness or flaw in a product that an attacker can use to cause harm.
Why it matters to you: Every product has some. The CRA expects you to find them, fix them and report the ones that are actively exploited.
How Pharus helps: Pharus checks the components in your products against CISA KEV and EUVD every 30 minutes.
- Actively exploited vulnerability
A vulnerability with reliable evidence that someone has used it to attack a system without the owner’s permission (CRA Article 3(42)).
Why it matters to you: This is what starts the 24-hour clock. The call is yours, and you must be able to justify it afterwards.
How Pharus helps: Pharus records the decision with its rationale, evidence and approvals: the record a regulator will ask for.
- Severe incident
An incident that harms, or can harm, a product’s ability to protect data or functions, or that has let malicious code into the product or into a user’s systems.
Why it matters to you: Like an actively exploited vulnerability, it must be notified within 24 hours.
How Pharus helps: The incident opens in Pharus with the CRA’s clocks already running.
- CVECommon Vulnerabilities and Exposures
A public ID for a known vulnerability, such as CVE-2025-55182 (React2Shell). It lets everyone talk about the same flaw.
Why it matters to you: Supplier advisories, scanners and authorities all refer to vulnerabilities by their CVE.
- CVSSCommon Vulnerability Scoring System
A score from 0 to 10 for how serious a vulnerability could be.
Why it matters to you: A high score doesn’t mean anyone is exploiting it, and a low one doesn’t mean nobody is. The CRA’s duty to report depends on exploitation, not on the score.
How Pharus helps: Pharus starts from evidence of exploitation in KEV and EUVD, which is what Article 14 asks about.
- CISACybersecurity and Infrastructure Security Agency
The US federal cybersecurity agency. It publishes KEV, the most-used list of exploited vulnerabilities.
Why it matters to you: CISA is American, but security teams all over the world watch KEV.
- KEVKnown Exploited Vulnerabilities, from CISA
CISA’s public list of vulnerabilities with evidence that they are being exploited in the wild.
Why it matters to you: A KEV listing is a strong sign that a vulnerability is actively exploited in the CRA’s sense. The call is still yours.
How Pharus helps: Pharus checks your SBOMs against KEV every 30 minutes and opens an incident when a component matches.
- EUVDEuropean Union Vulnerability Database
ENISA’s database of vulnerabilities, with its own list of those known to be exploited.
Why it matters to you: It is the EU’s counterpart to the American lists, run by the same agency that runs the SRP.
How Pharus helps: Pharus checks your SBOMs against EUVD as well as KEV.
- Security advisory
A public notice from a vendor about a vulnerability: what is affected, how serious it is and how to fix it.
Why it matters to you: Your customers expect one from you when your product is affected.
How Pharus helps: Pharus drafts it from the incident, ready for you to edit and publish.
- CSAFCommon Security Advisory Framework
A standard, machine-readable format for security advisories.
Why it matters to you: Your customers’ security tools can read CSAF automatically and see which of their products are affected, without anyone reading a PDF.
How Pharus helps: Pharus writes the CSAF advisory from the incident.
- VEXVulnerability Exploitability eXchange
A short statement of whether a product is actually affected by a vulnerability: not affected, affected, fixed or under investigation.
Why it matters to you: Most vulnerabilities in your components can’t be reached in your product. VEX says so, and saves you and your customers chasing false alarms.
How Pharus helps: Pharus reads VEX from your scanners and suppliers alongside your SBOMs.
The clocks
- Becoming aware
The moment you learn about an actively exploited vulnerability or a severe incident. The CRA’s clocks start here.
Why it matters to you: The clocks start when you become aware, not when you have finished investigating. When that moment was is something a regulator may ask about.
How Pharus helps: Pharus logs when you became aware, and every correction to it.
- Early warningWithin 24 hours
The first notification, within 24 hours of becoming aware: which product, what has happened and which countries the product is sold in.
Why it matters to you: It is short on purpose. Sending it on time matters more than having every answer.
How Pharus helps: Pharus has the text ready to paste into the SRP.
- NotificationWithin 72 hours
The second notification, within 72 hours: more about the product and the vulnerability or incident, and what you and your users can do.
Why it matters to you: It builds on the early warning and must include the measures you have taken.
How Pharus helps: Pharus fills it in from what has been logged in the incident since the early warning.
- Final report
The last notification: what happened, how severe it was and how it was fixed. For a vulnerability, no later than 14 days after a fix is available; for an incident, within one month of the notification.
Why it matters to you: It records how the case ended, so collect the evidence from day one.
How Pharus helps: The final report’s clock keeps running in Pharus after the busy part is over.
- User noticeArticle 14(8)
The message to the users of an affected product about the vulnerability or incident, and what they can do.
Why it matters to you: The CRA requires it on top of the reports to the authorities, where appropriate in a machine-readable format.
How Pharus helps: Pharus drafts it from the incident.
Day to day
- SBOMSoftware Bill of Materials
A list of every software component in a product, with versions: an ingredients list.
Why it matters to you: You can’t know whether a new vulnerability affects you without knowing what is inside. The CRA requires an SBOM for every product.
How Pharus helps: Pharus checks your SBOMs against KEV and EUVD every 30 minutes, and their quality against the CRA’s, BSI’s and CISA’s requirements.
- security.txt
A small file on your website (/.well-known/security.txt) that tells security researchers where to report a vulnerability.
Why it matters to you: It is the first place a researcher looks. Without it, a report can end up where nobody is watching.
How Pharus helps: Included in Pharus Free, with a reporting form and an inbox.
- Coordinated vulnerability disclosureCVD
How you take in vulnerability reports from outside, fix the flaw and publish it in agreement with whoever found it.
Why it matters to you: The CRA requires manufacturers to have, and follow, a policy for it.
How Pharus helps: Pharus hosts your policy and gives you an inbox for reports, free.
- Triage
The first look at a report or a match: is it real, does it affect us, and how urgent is it?
Why it matters to you: Quick, documented triage is what lets you meet a 24-hour deadline.
How Pharus helps: Every report in the Pharus inbox has a triage log.
- Reporting upstream
Telling the maintainers of a component, often an open-source project, about a flaw you found in it.
Why it matters to you: The CRA requires it (Article 13(6)), so the fix reaches everyone who uses that component.
How Pharus helps: Pharus helps you send it to the component’s maintainers.
- Support period
How long you will deliver security updates for a product. Under the CRA it must be at least five years, unless the product is expected to be in use for less.
Why it matters to you: You must tell buyers the end date, and handle vulnerabilities until then.
How Pharus helps: Pharus keeps an end date per release line and reminds you 90 days before it runs out.
- Product family
Products that share the same software or firmware and the same SBOM. They count as one, even when sold as different models.
Why it matters to you: It is how Pharus is priced: per product family, never per seat.
See pricing
What comes in 2027
- Product classDefault, important or critical
The CRA sorts products into default, important (class I or II) and critical, by their core functionality. Most products are default.
Why it matters to you: The class decides how you must show that the product meets the requirements. The reporting duties are the same in every class.
Check your class, free- Conformity assessment
The procedure that shows a product meets the CRA’s requirements, done by the manufacturer itself or, for some classes, by an independent body.
Why it matters to you: It must be done before a product is placed on the EU market from 11 December 2027.
- CE marking
The mark that shows a product meets EU requirements. From 11 December 2027 it also covers the CRA’s cybersecurity requirements.
Why it matters to you: Without it, the product can’t be sold in the EU.
- Annex IThe essential cybersecurity requirements
The CRA’s list of how a product must be built to be secure, and how you must handle vulnerabilities throughout its life.
Why it matters to you: It applies from 11 December 2027. The part on vulnerability handling builds on the same work as Article 14.
- Annex VIITechnical documentation
The CRA’s list of what a product’s technical documentation must contain, such as its design, its risk assessment and how vulnerabilities are handled.
Why it matters to you: It must be ready for products placed on the market from 11 December 2027, and kept for at least ten years.
How Pharus helps: Pharus builds the technical documentation for each product family.
