> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pharussecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Steps>
  <Step title="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](/monitoring/sboms) and [vulnerabilities](/monitoring/vulnerabilities).
  </Step>

  <Step title="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](/incidents/overview) and [clocks](/incidents/clocks).
  </Step>

  <Step title="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](/incidents/decision-record) and [audit trail](/reports/audit-trail).
  </Step>

  <Step title="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](/incidents/routing) and [SRP paste pack](/incidents/srp-pack).
  </Step>
</Steps>

After the filing, Pharus helps you [inform users](/incidents/inform-users), publish a [CSAF advisory](/disclosure/advisories) and [report the flaw upstream](/incidents/report-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:

<CardGroup cols={2}>
  <Card title="Disclosure page and inbox" icon="inbox" href="/disclosure/disclosure-page">
    A public report form, a hosted disclosure policy, security.txt and an inbox with a triage log. Included on Free.
  </Card>

  <Card title="Security advisories" icon="file-text" href="/disclosure/advisories">
    CSAF 2.0 advisories with VEX statuses, on your public advisory page and in a machine-readable feed.
  </Card>

  <Card title="Weekly exposure digest" icon="mail" href="/monitoring/weekly-digest">
    New exploited matches across every product family, every Monday morning.
  </Card>

  <Card title="Support periods" icon="calendar-clock" href="/monitoring/support-periods">
    An end date per release line, and a reminder before it runs out.
  </Card>

  <Card title="On-call paging" icon="siren" href="/on-call/rota">
    A rota that covers weekends, SMS paging and escalation when nobody acknowledges.
  </Card>

  <Card title="Board report and drills" icon="presentation" href="/reports/board-report">
    Quarterly evidence that vulnerability handling works, and an annual tabletop exercise.
  </Card>
</CardGroup>

## 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](https://www.pharussecurity.com/en/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

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    From sign-up to your first matched SBOM in about ten minutes.
  </Card>

  <Card title="Key concepts" icon="lightbulb" href="/concepts">
    Workspaces, product families, awareness, clocks and the words Pharus uses for them.
  </Card>

  <Card title="Plans and features" icon="layers" href="/plans">
    What Free, Starter, Core and Plus include, and how the trial works.
  </Card>

  <Card title="API reference" icon="code" href="/api-reference/introduction">
    Send SBOMs from CI, connect Dependency-Track and receive signed webhooks.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.