Skip to main content
Definitions as Pharus uses them. Where a term comes from a regulation, the article is given. For the background and the dates, read the CRA playbook.

​
Regulations and authorities

  • CRA (Cyber Resilience Act): Regulation (EU) 2024/2847, on cybersecurity requirements for products with digital elements. Its reporting duties in Article 14 apply from 11 September 2026; the rest applies from 11 December 2027.
  • Article 14: The CRA’s reporting duties: manufacturers report actively exploited vulnerabilities and severe incidents through the SRP, and inform the users of their products.
  • Product with digital elements: A software or hardware product and its remote data processing solutions (Art. 3(1)). The CRA covers those whose intended or reasonably foreseeable use includes a data connection to a device or network (Art. 2(1)).
  • ENISA: The European Union Agency for Cybersecurity. It runs the Single Reporting Platform and the EUVD.
  • SRP (Single Reporting Platform): ENISA’s platform where manufacturers file CRA Article 14 notifications. One filing reaches the coordinating CSIRT and ENISA. It is in English and has no API.
  • CSIRT: Computer security incident response team. Each EU member state designates one as coordinator under the CRA.
  • Coordinating CSIRT: The CSIRT that receives your CRA notifications, decided by Art. 14(7). See routing.
  • Authorised representative, importer, distributor: The economic operators in the Art. 14(7) cascade. Where they are established in the EU decides your coordinating CSIRT when you have no main establishment in the EU.
  • EEA Agreement: The agreement that extends EU rules to Norway, Iceland and Liechtenstein. The CRA is not yet part of it, so Norwegian manufacturers selling in the EU report to an EU CSIRT.
  • Nkom: The Norwegian Communications Authority, named as Norway’s CRA authority once the CRA is part of the EEA Agreement. It can’t receive CRA reports yet.
  • NSM: Nasjonal sikkerhetsmyndighet, the Norwegian National Security Authority. Receives notifications under digitalsikkerhetsloven. See Norwegian notices.
  • Datatilsynet: The Norwegian Data Protection Authority. Receives GDPR personal data breach notifications.
  • Finanstilsynet: The Financial Supervisory Authority of Norway. Receives DORA reports of major ICT-related incidents. See DORA.
  • digitalsikkerhetsloven: The Norwegian Digital Security Act, with its own incident notification duty to NSM.
  • GDPR: Regulation (EU) 2016/679. A personal data breach is notified to the data protection authority within 72 hours of becoming aware of it (Art. 33).
  • DORA: The Digital Operational Resilience Act, Regulation (EU) 2022/2554, for financial entities. Pharus classifies incidents against Delegated Regulation (EU) 2024/1772.
  • NIS2: Directive (EU) 2022/2555. Not yet Norwegian law; for a company established in Norway, Pharus shows it as tracked.

​
Reporting

  • Actively exploited vulnerability: A vulnerability that there is reliable evidence an attacker has exploited in a system without the owner’s permission (CRA Art. 3(42)). Reported under Art. 14(1).
  • Severe incident: An incident that harms, or can harm, the security of your product, such as a compromised build or update infrastructure (CRA Art. 14(3) and (5)).
  • Awareness: The moment your company became aware of the exploited vulnerability or severe incident. Every CRA deadline counts from it.
  • Early warning: The first report, within 24 hours of awareness (Art. 14(2)(a) and 14(4)(a)). Micro and small enterprises are not fined for missing this deadline (Art. 64(10)), but the early warning is still required.
  • Notification: The second report, within 72 hours of awareness (Art. 14(2)(b) and 14(4)(b)).
  • Final report: For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available (Art. 14(2)(c)). For a severe incident, within one month after the notification (Art. 14(4)(c)).
  • Corrective or mitigating measure: A security update or other fix that removes or reduces the vulnerability. Recording it starts the 14-day final report clock.
  • Determination: Your company’s documented answer on whether an incident is reportable under CRA Art. 14: was the vulnerability actively exploited, or is the incident severe? See decision record.
  • Inform users (Art. 14(8)): After you become aware of an actively exploited vulnerability or a severe incident, you inform the affected users and, where appropriate, all users, about it and about mitigations. See inform users.
  • Upstream report (Art. 13(6)): Reporting a vulnerability you found in a third-party component to whoever maintains it. See report upstream.
  • Support period: The period in which you handle vulnerabilities in a product and provide security updates (CRA Art. 13(8)). See support periods.
  • Annex VII: The CRA annex that lists what a product’s technical documentation contains. See technical documentation.
  • EU declaration of conformity: The manufacturer’s statement that a product meets the CRA’s essential requirements (Art. 28, Annex V).

​
SBOMs and vulnerabilities

  • SBOM: Software bill of materials: the list of components in a build of your product.
  • CycloneDX, SPDX: The two SBOM formats Pharus reads, in JSON. See SBOMs.
  • Component: One package listed in an SBOM.
  • purl (package URL): A standard identifier for a package, such as pkg:npm/lodash@4.17.21. Pharus matches components by purl.
  • OSV.dev: Google’s open vulnerability database. Pharus matches your components against it. It receives purls, never your company’s name.
  • CISA KEV: The Known Exploited Vulnerabilities catalog from the US Cybersecurity and Infrastructure Security Agency.
  • EUVD: ENISA’s European Vulnerability Database, which also marks vulnerabilities known to be exploited.
  • CVE: A public identifier for a vulnerability, such as CVE-2026-1234.
  • VEX: Vulnerability Exploitability eXchange: a statement of whether a product is affected by a vulnerability (affected, not affected with a justification, fixed, under investigation).
  • CSAF: The Common Security Advisory Framework, version 2.0: the machine-readable format for security advisories. See advisories.
  • TLP: Traffic Light Protocol, which marks how widely a document may be shared. Pharus publishes TLP:WHITE advisories.
  • security.txt: A file defined in RFC 9116, served at /.well-known/security.txt, that tells researchers how to report a vulnerability to you. See security.txt.
  • CVD (coordinated vulnerability disclosure): The process of receiving a vulnerability report, fixing the flaw and publishing it in agreement with the reporter. See disclosure page.