How to run the Article 14 clock without losing a night

Am I in scope?

Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026. If you are the manufacturer of a product with digital elements that you place on the EU market, it applies to you, whether the product is a device, firmware or software, and whether or not your company is established in the EU.

The obligation is not about vulnerabilities in general. It is about two things: an actively exploited vulnerability in your product, and a severe incident having an impact on the security of your product. Both start the same three-stage sequence, with slightly different fields and a different final report deadline.

Being outside the EU does not remove the obligation. It changes who files. If your main establishment is outside the EU you report through the CSIRT of the Member State where your authorised representative or your importers are, and Settings has a switch for that so your drafts name the right coordinating CSIRT.

Not sure which of those you are, or whether a sector law takes the product out of the CRA altogether? The free CRA Scope Check asks four questions and names the article behind each answer.

If you only want to know whether anything you ship is exploited right now, our free CRA Clock Check answers that from your SBOM in about fifteen seconds, with no account and nothing stored.

Reporting duties are separate from the essential requirements in Annex I. Publishing a coordinated vulnerability disclosure policy and a security contact is one of those requirements, and our free generator at /tools/security-txt produces both files.

What to do first

1. In Settings, fill in the manufacturer identity: legal name, address, main establishment country, and a reporting contact with a phone number.
2. Register every product you place on the EU market, with the versions that are still supported.
3. Work down the readiness checklist on the dashboard until it is empty. It includes registering on the reporting platform, which takes days, not minutes.

Dated regulatory changes, with links to the primary sources, are on /regulatory.

Getting a good SBOM

We match your product against exploitation feeds through its software bill of materials. Upload a CycloneDX or SPDX document in JSON, up to 25 MB, on the version page of a product. Larger files are rejected rather than silently truncated.

The quality of the match depends on one thing: component identity. A component is matchable when it carries a purl (package URL, for language and OS packages) or a CPE (for firmware, operating systems and appliances). A component with only a display name and a version cannot be looked up reliably, so it will not raise a case. If your generator omits purls, fix that before you tune anything else.

Any of these produce a usable file. Run them against the artefact you actually ship, not against your development tree, and generate a new SBOM for every release.

# Syft — container images, directories, archives
syft dir:. -o cyclonedx-json > bom.cdx.json
syft registry.example.com/gateway:3.2.0 -o cyclonedx-json > bom.cdx.json

# cdxgen — many language ecosystems, good purl coverage
cdxgen -o bom.cdx.json .

# Trivy — filesystem, image or root filesystem of a firmware build
trivy fs --format cyclonedx --output bom.cdx.json .
trivy image --format cyclonedx --output bom.cdx.json gateway:3.2.0

Upload it by hand once to see the match list, then automate it. The GitHub Action lives in this repository at .github/actions/upload-sbom and creates the version if it does not exist yet. No SBOM yet? Leave out sbom_path and the action generates a CycloneDX SBOM with Syft from the checked-out directory (scan_path, for example an unpacked firmware root filesystem) or from a container image (image).

- name: Upload to ExploitClock
  uses: JoshontheWebb/ExploitClock/.github/actions/upload-sbom@main
  with:
    api_key: ${{ secrets.EXPLOITCLOCK_API_KEY }}
    product_id: "12"                       # the number in the product page URL
    version: ${{ github.ref_name }}        # created if it does not exist
    sbom_path: bom.cdx.json

If you already run Dependency-Track, you do not need a second pipeline. Give us the instance URL, an API key and the project UUID, and we pull the current CycloneDX BOM for that project. The credentials are used for that one request and never stored.

curl -X POST "https://exploitclock.com/api/products/12/versions/34/import/dependency-track" \
  -H "Authorization: Bearer eck_..." -H "Content-Type: application/json" \
  -d '{"base_url":"https://dtrack.example.com","api_key":"odt_...","project_uuid":"1f0c..."}'

Uploading by API, from CI or from Dependency-Track all go through the same ingestion, so the evidence trail records the SBOM's SHA-256 either way. Re-uploading a corrected SBOM for a version keeps the existing cases attached.

No SBOM yet? The dashboard can create a sample product with a real SBOM and several known-exploited components, so you can see the whole flow before your own data is ready.

Reports from researchers: the vulnerability inbox

Feeds are one way to learn about a vulnerability; a security researcher or a customer telling you is the other. The CRA expects you to publish a coordinated vulnerability disclosure policy and to give people a way to report to you (Annex I Part II, points 5 and 6). The vulnerability inbox is that way: a public page of yours where anyone can report a suspected vulnerability in your products.

Switch it on in Settings under Vulnerability inbox. The page shows your disclosure policy, which you edit in the same place, and has a random address that is not derived from your account; "New address" replaces it at any time and retires the old one. With the inbox on, the security.txt generated in Settings lists the page as a second Contact line. The inbox is part of every plan, and it keeps working on an account without a subscription.

Every report gets a VR- reference and a 48-hour acknowledgment target. You are alerted on your alert channels when a report arrives, and once more if it is still unacknowledged after 48 hours. The Inbox page in the app lists the reports, with overdue ones marked. For each report you can:

• Acknowledge it. If the reporter left an email address, they get a short confirmation.
• Close it with a reason: not a vulnerability, a duplicate, out of scope, or already fixed.
• Convert it into a case on one of your products. The case opens in assessment and no clock starts: a report is not yet awareness of active exploitation, so you confirm that on the case, as with a feed match. Converting needs a product, so it needs a plan or the trial.

The page is rate limited, has a trap for bots, accepts no attachments, loads no analytics, asks search engines not to index it, and never stores the reporter's IP address. Reporters' names, email addresses and report text stay on the report: they are not copied into the evidence trail, into alerts or into a Jira or GitHub ticket. The evidence trail records the reference and what you decided.

How the 24h/72h/14-day clocks work

All three deadlines hang off one instant: awareness. Not detection, not the day the CVE was published, not the day the fix shipped. When you confirm awareness on a case, we write that timestamp and create the deadlines from it.

• Early warning, 24 hours from awareness. Both tracks.
• Notification, 72 hours from awareness. Both tracks. Note that it runs from awareness, not from the moment you filed the early warning.
• Final report. For a vulnerability: 14 days after a corrective or mitigating measure becomes available. For a severe incident: one month after the 72 hour notification, which is why submitting that notification re-bases the deadline.
• Informing impacted users is tracked alongside the 72 hour deadline as a soft deadline, because the regulation asks for it without undue delay rather than at a fixed hour. Publishing an advisory on your advisories page records it for you.

Before awareness there is one more timer. When a feed hit opens a case, we set an assessment deadline, four hours from detection by default, as our own prompt to decide. It has no legal force. It exists so that a case detected at 02:00 is not still sitting untouched at noon.

Deadlines are stored, not computed on a page load, so they survive restarts, and the clock on the case page counts down in your browser's local time while the underlying deadline stays in UTC. Every case can also produce a calendar file, so the deadline appears in the same calendar as the rest of your week even if every alert channel fails.

Where the clock comes from

We poll CISA KEV and the ENISA EUVD exploited list for evidence of exploitation, OSV for advisories against your components, EPSS for exploitation probability and NVD for CPE matching and severity, every 15 minutes. A hit on KEV or the EUVD exploited list opens a case. A high EPSS score never opens one: probability is a reason to look, not evidence that someone is exploiting your product.

Confirm or dismiss: what 'awareness' means

A case moves through five states: assessment when it is detected but no clock is running, open once awareness is confirmed, acknowledged when someone has taken it on, and finally closed or dismissed.

The step that matters is the first one. Commission guidance C(2026) 5252 §213 describes awareness as a reasonable degree of certainty reached after an initial assessment, so a raw feed match is not yet awareness. That gap is what the assessment state is for: check whether the matched component is really in the shipped build, whether the affected version range covers what you ship, and whether the exploited path is reachable in your product.

Then take one of two decisions, and take it explicitly.

1. Confirm awareness. The clocks start from the timestamp you confirm, or from an earlier time you enter if you learned about it before we did, for example from a customer report. Your assessment notes are stored with it.
2. Dismiss. If the product is not affected, close the case with a reason. On a component match you can also triage it as not affected, which requires a VEX justification and feeds the VEX export.

Both decisions are recorded in the evidence chain with who made them and when. That record is the point: an authority asking why you did not report something wants to see a dated, reasoned decision, not silence.

Importing VEX and comparing versions

If you already hold VEX statements, from your own analysis or from a supplier, you do not have to triage the same findings again. On the product page, under VEX statements, import a CycloneDX VEX or OpenVEX file (JSON, up to 5 MB) for the selected version; through the API you can also import one for the whole product. Each statement is matched to the version's findings by vulnerability id or alias and by component (package URL, BOM reference, or name and version).

• A not-affected statement with a justification, a fixed statement or a false-positive statement is applied exactly like a manual triage. The finding shows "VEX: <file>", and the statement appears in your VEX export.
• Statements that match nothing are listed back to you, never dropped silently.
• An imported statement carries forward: when a later version ships the identical component version, it covers that version's findings too, before a case would open. A component whose version changed is not covered, and a finding you triaged yourself is never overwritten.
• A VEX statement never closes or dismisses a case and never stops an Article 14 clock. If a case is already open for the vulnerability, the statement is recorded on the case's evidence trail for information, and the decision stays with you.

Each version also shows what changed since the previous version, or since any version you pick under "Compare with": components added, removed or upgraded, and findings newly introduced, resolved or still present, with the known-exploited ones (CISA KEV, ENISA EUVD) highlighted. Both work on every plan and in the trial, and through the API.

Closing a case, and stopping the alerts

A case you dismiss during assessment is finished: no clock ever ran, nothing was due, and the alerts stop at once. Most feed matches end this way, and you can clear a run of them together from the Cases list.

Closing a case whose clock has already started is different, because a notification may still be unfiled. Fixing the vulnerability does not remove the obligation to report it. Under Article 14 the duty is triggered by awareness, and shipping a fix is what starts the 14 day final report clock rather than ending anything.

So when you close, we first ask whether the product was affected at all. If further assessment established it was never affected, awareness is retracted: the deadlines are voided rather than missed, they are excluded from your on-time rate, and the case becomes a dismissal.

If it was affected, we ask about each outstanding notification separately, because filing the 24 hour early warning by hand and never filing the 72 hour one is the ordinary situation, and a single answer for the whole case would record the second as met.

• Filed, but outside ExploitClock. Tell us where and when, per notification. It counts as met, judged on time against its own deadline, with the venue written into the evidence chain. The time cannot be set before the case began, for the same reason a submission recorded here cannot be backdated.
• Not filed. The alerts stop, but that deadline stays on your compliance report as not filed and your on-time rate drops. We will not record it as met. That is deliberate: an authority asking about a gap should find your own dated account of it, not a clean sheet.

Whichever you choose, the nagging stops. A tool that keeps alerting about a case you have consciously finished just teaches you to switch alerts off, and then you miss the one that matters.

If your policy is the conservative reading, that detection equals awareness, turn on the auto-start setting in Settings. Cases then skip the assessment state and the 24 hour clock starts the moment a known-exploited component matches. This buys certainty and costs you false starts, because a withdrawn or misattributed advisory will have started a real clock.

Filing on the ENISA SRP

Filing happens on ENISA's Single Reporting Platform, and it is a manual job. There is no API at launch, so a named Assigned Representative signs in with EU Login and multi-factor authentication and completes the form. Nothing we do can submit on your behalf.

Two things to know before your first filing. First, the moment you became aware is a mandatory field on the early warning of both forms, labelled "Date and time when you become aware" (ENISA glossary v1.6, 21 October 2026; the vulnerability form opened on 11 September without it). Awareness is what the law measures, so we pre-fill it from your case and keep the record of how you established it in your evidence chain. Second, the platform's own 72-hour counter shows a due time 48 hours after your early-warning submission (ENISA FAQ Q26). File the early warning promptly and the portal will show "overdue" before the legal 72 hours from awareness are up. ENISA says its counters are for visibility and the legal deadline governs. On the case page you see both clocks. To see the gap for your own timings without an account, use the free deadline check.

What we can do is remove the writing. Generate the draft for the stage you are on and it arrives pre-filled from your product data in the platform's own field set: the same field names, the same character limits, the same required and optional status per stage. Every field is listed publicly at /srp-fields.

1. Open the case, generate the draft for the stage that is due.
2. Fill in every field marked required, then read the summary out loud once. Facts only, and mark anything that is an estimate as an estimate.
3. Copy it into the platform. The fill payload and the bookmarklet under SRP filler paste the values into the portal's own fields; the .txt and .json exports are there for the cases where you would rather work from a document.
4. Come back and record the submission with the reference the platform gave you. That satisfies the deadline and writes the receipt into the evidence chain.

Two traps worth knowing. The platform's 72 hour counter runs 48 hours from your early warning, so it disagrees with the legal deadline in both directions: early filers see "overdue" too soon, late filers see a generous date. Work to the legal clock. And an email to a CSIRT is not a formal notification, so if the platform is unreachable, record the attempt, use the fallback contact you stored in Settings, and file properly as soon as it is back.

Registering on the platform takes minutes with an EU Login account and multi-factor authentication. Validation of your Assigned Representative by your CSIRT runs in parallel and does not block filing: you may submit up to 20 notifications before it completes. ENISA asks manufacturers to register when they need to file rather than in advance, so the readiness checklist treats registration as a first-week item and validation as something that follows your first filing, not something that precedes it. Do line up a Primary and at least one Secondary Assigned Representative now. Every Assigned Representative of a manufacturer can see and update all of that manufacturer's notifications, whoever submitted them (ENISA FAQ Q9, 30 September 2026), so a deputy can pick up a case. Drafts are the exception: they stay in the account of the person who saved them, so submit the early warning rather than leaving it as a draft.

Telling your users: advisories page, feed and emails

Article 14(8) asks you to inform the impacted users about an actively exploited vulnerability, and about what they can do, without undue delay. It runs alongside the notifications, not after them. The public advisories page is where you do it.

Switch it on in Settings under Public advisories page. It has a random address of its own, separate from the vulnerability inbox's, lists your published advisories newest first, and gives each advisory a page with the affected product and versions, severity, CVE and EUVD ids, exploitation status, what users should do, fixed versions and the dates it was published and updated. Search engines may index it unless you untick "Let search engines index the page". It loads no analytics.

1. On the case, choose Publish advisory. The editor is pre-filled from public data about the vulnerability and from your fix record, never from the case notes, the evidence or a vulnerability report.
2. Choose the languages (English, German, French, Spanish, Italian) and write each one yourself. Nothing is machine-translated.
3. Publish. That records that users were informed, with the channel "public advisory page", which is the Art. 14(8) step on the case. Later updates keep a revision history and never move the date users were first informed. Withdrawing an advisory leaves a withdrawal notice in its place rather than a missing page.

Every advisory is also machine-readable: a CSAF 2.0 document built from the published fields only, an Atom feed of the page, and a CSAF provider-metadata.json with a directory listing (index.txt, changes.csv), so a customer's tooling can pick advisories up on its own. With the page on, the security.txt generated in Settings carries a CSAF line pointing at it.

Emailing your customers. In Settings, paste the addresses that should hear from you, up to 2,000, for every product or for one. When you publish, tick "Also email the customer distribution list": each address gets its own short message with a link to the advisory and an unsubscribe link that works without logging in, sent in the background, with the sent and failed counts in the evidence trail. An address that unsubscribed is never added or emailed again, and at most 4,000 emails per account go out in any 24 hours. Recipients' addresses never enter the evidence trail, alerts or logs.

The page, the feed and the CSAF files are part of every paid plan and the trial; emails to your customer list start with a paid plan. Publishing and emailing need a logged-in session, so an API key cannot put words on your public page or email your customers.

Telling the upstream maintainer

Article 13(6): a manufacturer that identifies a vulnerability in a component, open source included, reports it to the person or entity that maintains the component. Every vulnerability case has an Upstream maintainer panel for that step.

For a case opened from your SBOM, the panel shows the component, its package URL and where to report: the security contact, issue tracker, repository or website your SBOM gives for that component (CycloneDX externalReferences, SPDX homepage and download location), the repository's security policy and private vulnerability reporting page on GitHub, and the project links in the advisory. When none of these is known, it says so. Nothing is fetched from the internet to build the panel; the links come from data ExploitClock already holds.

• Record upstream notification: the channel, the date, an optional reference such as a GHSA id or a link, and a note.
• Not needed (already public), with a reason, typically for a vulnerability that already has a CVE and is listed as known exploited: the maintainer already knows.

Either is written to the evidence trail and appears on the case's timeline and in the technical-file export. If you found the vulnerability yourself, report it privately through the maintainer's security policy or security.txt. For an identifier, ask the maintainer whether it is a CVE Numbering Authority (CNA); if it is not, request a CVE from a CNA of last resort such as MITRE (cve.org), or contact ENISA, which runs the European Vulnerability Database (EUVD). The panel is on every vulnerability case, on every plan.

Tickets in Jira and GitHub

The fix work usually lives in your engineering tracker, not here. Connect it once in Settings › Integrations:

• Jira Cloud: your site address (atlassian.net), the Atlassian account email, an API token, a default project key, the issue type and optional labels.
• GitHub Issues: a fine-grained personal access token, a default repository and optional labels. A token limited to that one repository with access to Issues is enough.

"Test connection" checks the settings before you rely on them. Then, on any open case, Create Jira ticket or Create GitHub issue opens a ticket in one click, and Link existing attaches one you already have. The ticket carries the case title, the product and version, the advisory ids, the exploitation evidence, the Article 14 deadlines in UTC and a link back to the case. A case opened from your vulnerability inbox is named by its VR- reference only: nothing the reporter wrote, and no name or email address, goes into the ticket.

ExploitClock checks each linked ticket's status every 15 minutes and records every change in the evidence trail. When the fix ticket is done, the case asks you to record the date the fix became available, which starts the 14-day final-report clock. A closed ticket never changes the case or its deadlines on its own.

Tokens are stored encrypted, shown again only as their last four characters, and never returned to an API key or written to a log line or an error message. Only Jira Cloud addresses (atlassian.net) and api.github.com are contacted, through the same outbound checks as every other address you give us. Tickets are part of every paid plan and the trial; creating, linking and unlinking also work through the API.

Setting up alerts that actually reach you

A clock nobody hears is worse than no clock, because it produces a record of a deadline you missed. Configure at least two independent channels in Settings so a single outage cannot silence you.

Please do not use the Unsubscribe button your mail app shows on our emails. Our mail provider treats it as "block this sender", and that blocks deadline alerts as well as the daily summary. To stop the summary, switch it off in Settings. If an alert address does get blocked, by an unsubscribe, a bounce or a spam report, the dashboard's Alerts line turns red, the evidence chain records it, and we warn you on your other channels; the owner of the address can re-enable it from Settings.

• Email to an escalation address, with optional CC addresses. Use a shared mailbox that is monitored out of hours, not one person's inbox.
• Slack or Microsoft Teams incoming webhook. Point it at the channel your on-call people actually watch.
• A generic webhook into your own paging system. Each request is signed with HMAC-SHA256 in the X-ExploitClock-Signature header so you can verify it came from us. Each request also carries one alert id, as alert_id in the JSON body and in the X-ExploitClock-Alert-Id header; a retry of a failed delivery reuses the same id, so deduplicate on it and you will never page twice for one alert.
• SMS for clock-critical alerts, where the deployment has it configured.
• The live dashboard, which pushes alerts over a WebSocket to anyone on the account with the page open.

Alerts escalate as a deadline approaches, relative to that deadline's own window: clocks longer than 24 hours (the 72 hour notification, the final report) get a nudge 24 hours before they are due, then every deadline is reminded at 12 hours, 6 hours, 2 hours, 1 hour and 15 minutes remaining where that is shorter than the deadline's own window (so a 4 hour assessment starts at 2 hours, and a 24 hour early warning at 12), and once more when it goes overdue. Only the tightest threshold crossed fires, so a case you leave alone does not produce a wall of duplicates. Every send is recorded as evidence.

There is also a daily heartbeat digest, sent at an hour you choose, listing active cases and new matches. Its second job is proof of life: if the heartbeat stops arriving, your alerting is broken, and you want to learn that on a quiet Tuesday.

Test it, do not assume it

1. Settings, then send a test alert. It goes to every configured channel.
2. Check each channel actually received something, including on a phone with the screen locked.
3. If a webhook is silent, check that its URL is HTTPS and publicly resolvable. We refuse to fetch internal addresses.
4. Run a drill once a quarter, which is the only honest test of the whole chain.

Behind a company mail filter or web filter

Deadline alerts come from alerts@exploitclock.com. The daily summary, invitations and trial emails come from digest@exploitclock.com. Both are signed for exploitclock.com with SPF, DKIM and DMARC, so an allow rule for the domain is safe to add.

• Microsoft 365: an administrator adds a mail flow rule in the Exchange admin center that bypasses spam filtering for mail from exploitclock.com, ideally only for messages that pass authentication.
• Google Workspace: an administrator adds exploitclock.com to an approved senders list under Apps, Google Workspace, Gmail, Spam, phishing and malware.
• Proofpoint, Mimecast and other mail gateways: add exploitclock.com to the organisation's safe-sender list.
• Your own mailbox: add alerts@exploitclock.com to your contacts, send a test alert from Settings, and check that it lands in the inbox, not in junk.

A mail filter cannot hold back Slack, Teams or a webhook. That is what the second channel is for.

Some web filters block domains that were registered recently or are not yet categorised. If the site does not open on your company network, ask IT to allow exploitclock.com and its subdomains, and our login page at dev-cq05f8c8g7owecvo.eu.auth0.com. If your network blocks WebSockets, the dashboard says so and refreshes every minute instead; nothing is lost.

If your webhook endpoint only accepts requests from listed addresses, write to support@exploitclock.com for the current list of addresses our requests come from.

Deputies and holidays

Twenty-four hours runs through weekends, holidays and flights. One person cannot cover it, and the reporting platform makes the same assumption by asking for a Primary and up to twenty Secondary Assigned Representatives.

In ExploitClock, several logins share one account. Invite colleagues from Settings as an editor or a viewer, and they see the same products, cases, drafts and evidence you do. Everything that matters at 3am is shared by every editor: products, SBOM uploads, cases, confirming or dismissing awareness, drafts, alert settings and API keys. A viewer sees the dashboard, products, cases, filings, evidence, the vulnerability inbox, tickets and advisories and can change none of it, which suits a manager or an auditor; the server enforces that on every request, not just the page. The person who created the account is the account owner, and only the owner can change the plan and billing, invite or remove members, switch a member between editor and viewer, export the account, delete the account and start a manual feed run. On a 24 hour deadline an access denied message for the person on duty would be a bug, not a control, so give everyone on the rota editor access. Accountability comes from the evidence chain, which records the real person behind every action and every role change.

Assign each case an owner so it is clear who is driving it, and change the owner when that person goes off shift. Your plan sets how many people can be on the account.

A workable rota

1. Name a primary and at least one deputy, and put both on the reporting platform as Assigned Representatives.
2. Give both of them the alert channels, not just the primary.
3. Before a holiday, reassign open cases rather than assuming someone will notice.
4. Keep the CSIRT fallback contact in Settings current, so whoever is on duty does not have to find it.

Single sign-on

On the Unlimited plan your team can log in through your own identity provider (SAML, Microsoft Entra ID or OIDC), with "Sign in with your company SSO" on the login page. It is not self-serve: we set it up with your IT team, and we can make it mandatory for your email domains, so that a password or Google login with a company address is refused. Settings shows whether it is on, the connection, the domains and whether it is enforced. Write to support@exploitclock.com to set it up.

The evidence chain and what to hand an authority

Every state change writes an evidence event: the advisory as we fetched it, the SBOM we ingested with its SHA-256, the match that fired, your assessment decision, the confirmation of awareness, each alert sent, each draft generated and each submission recorded.

Each event is hashed with SHA-256 over its canonical content plus the previous event's hash for your account, so the log is a chain. Editing or deleting a row breaks verification from that point onward, and nothing in the product edits or deletes evidence rows. You can run the verification yourself at any time, and it is embedded in every export.

Once a day the head of your chain is sent to an independent RFC 3161 time-stamp authority, which returns a signed token proving that exact chain head existed at that time. That is what makes the trail hard to argue with: not our word, a third party's signature. The receipt is downloadable and verifiable offline with nothing but OpenSSL.

printf '%s' "<chain head hash>" > head.txt
openssl ts -verify -data head.txt -in receipt.tsr -CAfile tsa-ca.pem

When an authority, a customer's security team or a notified body asks, export the bundle for the case. It contains the case, its deadlines and whether each was met, the drafts and submission references, the full evidence chain and the verification result. There is also a printable compliance report for the whole account and for a single case, which is usually the right thing to send to a board or an auditor.

What to hand over

1. The evidence export for the case in question.
2. The timestamp receipt covering the period, if you want third-party attestation of the dates.
3. The compliance report, as the readable summary that sits on top of both.

The technical file and the support period

Your technical documentation has to describe how you handle vulnerabilities (CRA Annex VII point 2(b) and (c), Annex I Part II). Each product page has a Technical file: vulnerability handling export: the part of that documentation ExploitClock can vouch for, assembled from the evidence log for a period you choose, the last 12 months by default. It is one section of your technical file, not the whole of it.

• The support period, and the versions with every SBOM (format, SHA-256, upload date, component count).
• How vulnerabilities are handled: the monitoring sources and how often they run, which kinds of alert channel are set up, the vulnerability inbox and its policy, the security.txt contact, the advisories page and the size of the distribution list.
• The figures for the period: matches found and how they were triaged, VEX included; cases opened and closed; each Article 14 notification drafted, submitted, on time or late; user advisories; upstream reports; and the median time from awareness to early warning.
• A table of the cases, and the result of verifying the evidence chain with the latest RFC 3161 timestamp.

Print it or save it as PDF from the browser, or download it as Markdown or JSON (also from the API). It never contains reporters' personal data, case notes or alert addresses, and each export is recorded in the evidence trail. It is part of every paid plan and the trial.

Support-period alerts. Declare when support ends on the product ("Support ends"). We alert you through your alert channels 90, 30 and 7 days before that date and on the day itself, once each, and record each alert in the evidence trail. The product page and the dashboard show how many days are left.

Rehearsing

The first time you run this process should not be the first time it matters. A drill opens a case marked [DRILL] on a product you choose, and it behaves like a real one: real deadlines, real alerts to your real channels, real drafts, real evidence. It is excluded from your compliance statistics and labelled everywhere, so nobody mistakes it for an incident.

Run one from the dashboard, pick the vulnerability or the incident track, and then work the case exactly as you would a real one. Drills are limited to a handful per hour, which is more than any honest rehearsal needs.

What a good drill proves

1. The alert reached a human on a phone, out of hours, within minutes.
2. That human could sign in to the reporting platform without asking anyone for a credential.
3. The 24 hour draft was complete enough to file, and someone senior enough to approve it was reachable.
4. The evidence export produced something you would be willing to hand to an authority.

Time each step and write down what broke. The number that matters is not how fast you can file, it is how long the case sat before anyone looked at it. Close the drill when you are done so it does not clutter the case list.

Closing the drill scores it out of 100 from what is on its record: how long awareness took, whether each notification went in on time and complete, whether the final-report flow started, the coordinating CSIRT, the user and upstream steps, and the evidence chain. The drill report (the score badge on the case) lists every criterion with the evidence it came from, what to fix next, and how this drill compares with your earlier ones. Print it or save it as PDF for the file. To try the exercise without an account first, use the free 24-hour drill.

Plans, trial, cancelling

New accounts get 14 days of Team-level access with no card. Register products, upload SBOMs, run a drill and file nothing: the trial is meant to be used on real products, because a trial on a toy product proves nothing.

Plans differ mainly in how many products you monitor and how many people are on the account: Starter is one product, Team is five, Unlimited has no product cap. Versions, SBOM uploads, cases, drafts, alerts and the evidence chain are not metered on any plan, because rationing those would be rationing compliance. Beyond that, single sign-on is part of Unlimited; the trial includes everything on Team except emailing advisories to your customer list, which starts with a paid plan; and the vulnerability inbox works on every account, with or without a plan. Prices are on /pricing.

Payment goes through Stripe. Plan changes, invoices and payment methods live in the Stripe billing portal, reachable from the Billing page, and switching plans mid-cycle is prorated. Annual billing costs ten months instead of twelve.

Cancelling is self-serve on the Billing page and takes effect at the end of the period you have paid for. You keep full access until then. After that the account drops to no product monitoring, so cancel deliberately: an unmonitored product is an unmonitored clock. Your data is not deleted by cancelling. Deleting it is a separate, explicit action.

Export, deletion, leaving

Both are self-serve in Settings for the account owner, and neither needs a support ticket. Invited members cannot export or delete the account; Settings tells them who the owner is.

Export gives you a single JSON document with your account and each member's role, products, versions, SBOM records, matches, VEX imports, cases, deadlines, drafts, settings, vulnerability reports, ticket links, published advisories with your customer distribution list, and the full evidence chain. Integration tokens are never in it. Take one before you cancel, and take one whenever an auditor asks for a snapshot. The evidence chain in the export verifies on its own.

Deletion removes the account and everything in it, including the evidence chain, and you confirm by typing your username. It is not reversible and we cannot restore it afterwards. Think about your own retention duty first: an evidence trail you deleted is one you cannot show anybody.

If you are leaving for another tool, the useful pieces travel: the SBOMs are your own files, the VEX export is CycloneDX 1.6 or OpenVEX, advisories export as CSAF 2.0, and the drafts export as text or JSON in the platform's field set. Cancel the subscription, take the export, then delete the account, in that order.

What we store, where it is hosted and who processes it is set out on /security and /privacy.

Questions manufacturers ask

Getting help

Email support@exploitclock.com. We answer within two business days, and within one business day on Unlimited.

Prefer to see it on a call? In a 30-minute walkthrough (in English) we run one of your SBOMs through ExploitClock while you watch and answer your Article 14 questions. Book a walkthrough

The API reference is at /docs (Bearer key, every paid plan).

Always include the case id if your question is about a case. It is the number in the case page URL, and with it we can look at the exact deadlines, drafts and evidence you are looking at. Without it, the first reply is just us asking for it.

A useful message says what you expected, what happened, and the time it happened in UTC. If it is about a missed alert, say which channel and we will check whether the send was recorded. If it is about a match you think is wrong, send the component name and version and the advisory id.

If you have found a security problem in ExploitClock itself, put "security" in the subject line. We acknowledge those within two business days. Our own disclosure policy and security contact are on /security.

Every login uses two-factor authentication: a code from an authenticator app, from the first sign-in. It cannot be switched off, because an ExploitClock login can confirm, dismiss and export entries in your legal reporting record. If you lose the phone with your authenticator, email us from the address on the account; once we have confirmed it is you, we reset two-factor and you enrol again at your next login.

If a real deadline is at risk and something here is blocking you, say so in the first line of the email. We would rather be interrupted than read about it afterwards.