Skarp CRA

Setup

Skarp CRA is an MCP server. You talk to it through Claude or another MCP client — there is no app to learn.

Connect it

Add it as a connector, using this URL:

https://cra.skarp.app/mcp

In Claude: Settings → Connectors → Add custom connector, paste the URL, and click connect. You will be asked for your email address and sent a six-digit code. Enter the code and you are done — there is no password and no token to copy.

A code rather than a link, deliberately: a link opens in whichever browser your mail is in, which is often a phone, while the connection is waiting in a tab on your laptop.

Other MCP clients work the same way if they support remote servers over Streamable HTTP with OAuth. If yours needs a bearer token instead, get one from /access — it is shown once.

Ask it these three things first

Nothing needs setting up before you start. Type in your own words; these are what the answers look like.

1. "Does the Cyber Resilience Act apply to what we ship?"

It walks you through Annex III and Annex IV with you and records the answer with your reasoning. It will not guess from your product's name — the class decides whether you need a notified body, and a wrong answer there is the expensive kind.

2. "We ship a Java service — are any of our dependencies known to be exploited?"

Give it your SBOM and it checks every component against OSV, CISA's Known Exploited Vulnerabilities catalogue, and EPSS, then re-checks nightly. Matches arrive as questions to answer, not as findings about your product.

3. "We just found out a flaw in our product is being exploited. What now?"

This is the one with a clock. From 11 September 2026 an actively exploited vulnerability must be notified within 24 hours. It starts the 24-hour, 72-hour and 14-day deadlines from when you became aware rather than when you typed it in, and drafts the ENISA report for you to file.

It does not pick a CSIRT for you. Reports go to the coordinator of the Member State where you have your main establishment, and the Single Reporting Platform routes on your registration — so the useful thing is being registered before you need it, which is what the readiness check is for.

“Isn't it safer not to scan?”

The clocks run from awareness, so not looking can seem like the careful option. It is not, for three reasons.

Not looking is its own breach. Article 13(5) says manufacturers “shall exercise due diligence when integrating components sourced from third parties”, open-source ones included, and Annex I Part II(1) requires you to identify and document your vulnerabilities and components. The regulation does not merely allow looking. It requires it.

A scan does not make you aware in the legal sense. Article 14 is about an actively exploited vulnerability contained in the product. A feed match is not that — version ranges over-match, vendored patches are invisible to them, and the affected code may never run in your build. It is a question about whether you are affected, and only a person can answer it. That is why a scan here produces candidates and stops: the clock starts when you decide, not when a feed matches.

You will find out anyway, later. A researcher emails you, a customer forwards a bulletin, an upstream maintainer publishes. The 24-hour clock starts then regardless — you simply have less of it left, and nothing on record showing when you learned. Ruling a candidate out with a documented reason is evidence of diligence; never having looked is not a defence.

What it will not do

It records the determinations you make and shows you what is missing. It does not make them for you: it will not decide your product class, judge whether a justification is good enough, or tell you that you are compliant. It cannot certify conformity, and where your class requires a notified body only that body can assess it.

Reading the source

The server is at github.com/ozzynxe/cra, under the AGPL. That matters more here than for most tools. This one tells you what the regulation requires and what your record is still missing, and the only way to check a claim like that is to read what the code actually does.

The Annex I and Annex II catalogues are versioned data files, and each item records the article it is drawn from and the date the text was last reconciled against the Official Journal — so a paraphrase can be checked against the regulation rather than taken on trust. Coverage is generated from those same files.

Free, and what costs money

One product is free, with unlimited colleagues: classification, the Article 13(2) risk assessment, the Annex I and Annex II checklists with evidence, daily scanning, the Article 14 reporting clocks, and the Annex VII gap report. No card.

Paid adds four more products and the last step — freezing the technical file, drawing up the Declaration of Conformity, signing it off, and recording a product as placed on the market. Almost nobody needs that before December 2027. See pricing.

You can take everything with you at any time, on any plan: ask it to export the product, or download the full archive from the console.

Two dates, and the gap between them

Those are the wrong way round, and it is worth knowing why. Article 71 applies the Regulation from December 2027 — “however, Article 14 shall apply from 11 September 2026”. So from this September you owe a 24-hour notification, while Annex I Part II, which requires you to have a vulnerability handling process, does not bind for another fifteen months.

Which means the process is worth having before it is required. Not to satisfy Part II early — to be able to answer the clock that starts first. Knowing what you ship, hearing when one of those components turns out to be exploited, and having somewhere for a finder to send a report are the three that make the difference at hour one, and all three are on the free plan.

Something wrong?

Email cra@skarp.app, or open an issue. If the tool told you something that turns out to be inaccurate, that is the report we most want to receive — more than a patch, and by some distance.