What the CRA requires, and what we do about it

Twenty-five paragraphs. These are the duties that attach to placing a product with digital elements on the EU market.

13(1)

The obligation

Ensure the product has been designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I Part I.

What Skarp CRA does

Puts each of the 22 requirements in front of the agent working in your repository, together with the risk from your own assessment that makes it applicable and a note of what good evidence looks like. Status and reasoning are recorded per requirement, and evidence is stored by value and hashed with its provenance — a git SHA, a CI run, a tool and version. The engineering is yours; this is what turns each requirement into a specific, evidenced task next to the code rather than a line in a PDF.

list_requirements · update_requirement · attach_evidence

13(2)

The obligation

Undertake a cybersecurity risk assessment and take its outcome into account during planning, design, development, production, delivery and maintenance.

What Skarp CRA does

Your agent drafts risks from the codebase it is sitting in. You accept, amend or reject each one — a drafted risk determines nothing until decide_risk is called with a rationale. Confirming freezes a hashed version.

start_risk_assessment · propose_risks · decide_risk · confirm_risk_assessment

13(3)

The obligation

Document the assessment and update it during the support period. It must analyse risks based on intended purpose, reasonably foreseeable use and conditions of use, taking account of how long the product is expected to be in use; indicate whether and how the Annex I Part I(2) requirements apply and how they are implemented; and indicate how Part I(1) and the Part II vulnerability handling requirements are applied.

What Skarp CRA does

The four inputs the paragraph names are mandatory before an assessment can be confirmed. Each decided risk names the requirements it makes applicable, which becomes the recorded basis on each one, and an implementation note records how it is met. The assessment is derived stale when the product moves under it — a reclassification, a lifecycle change — so "updated as appropriate" has a trigger rather than a reminder. The paragraph's last sentence is asked for separately and confirming is refused without it: the risks answer Part I(2), and how you apply Part I(1) and the Part II vulnerability handling requirements are statements about the whole product that no per-risk determination produces. Both freeze inside the hashed assessment, so Annex VII(3) cites all of 13(3) rather than two thirds of it.

start_risk_assessment · decide_risk · confirm_risk_assessment · get_risk_assessment

13(4)

The obligation

Include the risk assessment in the technical documentation. Where an essential requirement is not applicable, include a clear justification.

What Skarp CRA does

Annex VII(3) does not report complete without a confirmed, non-stale assessment, and marking a requirement not applicable is refused without a justification. Nothing is ever ruled out automatically: confirming an assessment marks the risk-named requirements applicable and leaves the rest undetermined, which still reads as a gap.

assemble_technical_file · update_requirement

13(5)

The obligation

Exercise due diligence when integrating third-party components, including free and open-source components, so they do not compromise the product's cybersecurity.

What Skarp CRA does

Your SBOM is stored by value and checked daily against the OSV advisory database and CISA's Known Exploited Vulnerabilities catalogue. That covers knowing what you ship and what is known to be wrong with it. There is no per-component record of diligence at the moment of adoption — what was checked, by whom, when.

record_sbom · scan_advisories · list_advisory_candidates

13(6)

The obligation

On identifying a vulnerability in an integrated component, report it to whoever manufactures or maintains that component, and share any fix you developed.

What Skarp CRA does

Nothing. Confirming an advisory on a third-party component is the moment this duty arises and the tool knows it, but it does not prompt for the upstream report or record that you made one. Attach it as evidence against Annex I Pt II(2) in the meantime.

13(7)

The obligation

Systematically document relevant cybersecurity aspects, including vulnerabilities you become aware of and relevant information provided by third parties, and update the risk assessment where applicable.

What Skarp CRA does

Vulnerability and incident records carry status, severity and remediation references; advisory candidates from OSV and CISA KEV are the third-party half. Every change writes an attributed audit row in the same database transaction as the change itself, so a failed audit write fails the operation rather than leaving an unrecorded edit.

record_vulnerability · update_vulnerability · get_recent_activity

13(8)

The obligation

Handle vulnerabilities effectively during the support period, in accordance with Annex I Part II. Determine the support period from the expected time in use — at least five years unless the product is expected to be in use for less. Record what you took into account in the technical documentation, and have policies and procedures, including a coordinated vulnerability disclosure policy, for processing reported vulnerabilities.

What Skarp CRA does

Vulnerability handling is the Annex I Part II section below and the Article 14 clocks. Your coordinated vulnerability disclosure policy URL and security contact are recorded and checked before an incident rather than during one. The support period is recorded with its reasoning, which is the half of 13(8) people forget: the paragraph puts the information taken into account in the technical documentation, so a date alone leaves Annex VII(4) unmet even though it looks filled. A period under five years is refused unless you state the expected use time — the paragraph's only exception, and one that has to be claimed rather than arrived at by choosing a nearer date. The floor is measured in calendar years, not elapsed days.

set_support_period · set_submitter_profile · check_reporting_readiness

13(9)

The obligation

Keep each security update available for at least 10 years after it is issued, or for the remainder of the support period if longer.

What Skarp CRA does

Nothing. Track update availability outside the tool.

13(10)

The obligation

Where substantially modified versions of a software product have been placed on the market, Annex I Pt II(2) compliance may be ensured for the latest version only, provided earlier users can reach it free of charge and without adjusting their environment.

What Skarp CRA does

Nothing. The position you take can be attached as evidence against Annex I Pt II(2) so it lives with the file rather than in someone's head.

13(11)

The obligation

Where public archives of historical versions are maintained, clearly inform users of the risks of using unsupported software.

What Skarp CRA does

Nothing.

13(12)

The obligation

Before placing the product on the market: draw up the technical documentation, carry out (or have carried out) the conformity assessment procedure, and where conformity is demonstrated, draw up the EU declaration of conformity and affix the CE marking.

What Skarp CRA does

The technical file is assembled as an Annex VII gap report first and can then be frozen with a content hash. The Annex V declaration is generated bound to that hash, and a sign-off binds a named signatory to a specific version — editing afterwards shows as a stale signature rather than silently still valid. The conformity assessment procedure and the CE marking are acts you perform; where your product class requires a notified body, only that body can assess conformity.

assemble_technical_file · generate_declaration_of_conformity · sign_off · get_conformity_status

13(13)

The obligation

Keep the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years after the product is placed on the market, or the support period if longer.

What Skarp CRA does

Evidence is stored by value rather than as a link that rots, the audit trail is append-only, and the statutory record is copied to an archive under S3 Object Lock with per-object retention never shorter than the ten years 13(13) requires. The technical file reports the date your documentation has to be kept until, computed from the release you placed on the market and your support period — and says the period has not started where you have placed nothing.

attach_evidence · list_evidence

13(14)

The obligation

Have procedures keeping series production in conformity, taking account of changes in the development or production process, in the product's design or characteristics, and in the harmonised standards, certification schemes or common specifications the declaration relies on.

What Skarp CRA does

The risk assessment is derived stale on reclassification or a lifecycle change, and signatures go stale when the frozen file is edited. Nothing watches the harmonised standards themselves — they are recorded in the Annex VII(5) slot and not monitored for change.

get_conformity_status · get_risk_assessment

13(15)

The obligation

Ensure the product bears a type, batch or serial number allowing its identification, or that the information is on the packaging or an accompanying document.

What Skarp CRA does

Nothing. This is an identifier on the artefact or its packaging.

13(16)

The obligation

Indicate the manufacturer's name and contact details on the product, its packaging or an accompanying document, and in the Annex II user information.

What Skarp CRA does

Nothing. A legal name and a security contact are recorded, but those serve Article 14 reporting and are a different obligation — do not treat one as evidence of the other.

13(17)

The obligation

Designate a single point of contact letting users communicate directly and rapidly, easily identifiable to users, allowing them to choose their means of communication rather than forcing automated tools.

What Skarp CRA does

The contact address is recorded and surfaced in reporting readiness. Whether it is easily identifiable and offers a choice of channel is an organisational fact the tool cannot check.

set_submitter_profile

13(18)

The obligation

Ensure the product is accompanied by the information and instructions to the user set out in Annex II, and keep them available for at least 10 years or the support period if longer.

What Skarp CRA does

All fifteen items are a checklist, worked one at a time: nine numbered points with the six sub-points of point 8 listed separately, because each is a distinct thing a reader has to find. Each is either provided — with where a user actually finds it — or ruled out with a justification. Four are conditional in the annex's own words, and those still need a reason, or "where applicable" becomes a way to empty the annex. Annex VII(1) reports the coverage item by item instead of accepting an attached document and hoping it says the right things. What the tool cannot do is read your manual and tell you whether it is true.

list_user_information · update_user_information · attach_evidence

13(19)

The obligation

Specify the end date of the support period, at least the month and year, clearly at the time of purchase; and where technically feasible, display a notification when the product reaches end of support.

What Skarp CRA does

The end date is recorded with the determination, and where you publish it can be recorded alongside — the tool cannot check that a page says what you think it says, but it keeps the address with the record. Everyone on the product is warned at 180, 90, 30 and 7 days, and once when the period passes. It cannot display a notice inside your product, which is the other half of this paragraph.

set_support_period

13(20)

The obligation

Provide either a copy of the EU declaration of conformity or a simplified one carrying the exact internet address of the full declaration.

What Skarp CRA does

Both forms. The simplified one is refused without the exact internet address of the full declaration, because that address is the entire reason 13(20) permits a short form — an address-less one is not a shorter declaration, it is a non-compliant one. It records the address exactly as given and never fetches it: the tool cannot confirm what is published there, and it says so rather than implying a check it did not make. It also carries the hash of the full declaration it points at, so re-issuing that one makes a stale short form detectable.

generate_declaration_of_conformity · generate_simplified_declaration

13(21)

The obligation

On knowing or having reason to believe the product or your processes are not in conformity with Annex I, immediately take corrective measures, or withdraw or recall the product.

What Skarp CRA does

Nothing. There is no non-conformity record, so "we knew, we did this, on this date" has to be attached as evidence.

13(22)

The obligation

On a reasoned request from a market surveillance authority, provide all information and documentation demonstrating conformity, and cooperate on measures to eliminate the risks posed.

What Skarp CRA does

The technical file is the dossier such a request asks for, and the evidence list enumerates what is held, and export_product returns everything about a product in one document — free, on every plan, with the full archive downloadable from the console. What there is no packaging for, and no record that a request was received, what was provided, and when.

assemble_technical_file · list_evidence

13(23)

The obligation

A manufacturer ceasing operations must inform the relevant market surveillance authorities, and as far as possible the users, before the cessation takes effect.

What Skarp CRA does

Nothing. A one-off business event discharged by writing to people.

13(25)

The obligation

Market surveillance authorities may request the software bill of materials for a dependency assessment conducted by ADCO.

What Skarp CRA does

The SBOM is stored by value, so it can be produced on request in the form it was given.

record_sbom

This is what applies from 11 September 2026, and it is the half with a clock on it. Every deadline here runs from when you became aware, however that happened — a researcher, a customer, your own testing, or the daily scan described below. The regulation does not oblige you to go looking, and nothing here is a guarantee that you will find out in time. These tools and the scanning are free — nobody should meet a paywall while a 24-hour statutory clock is running.

14(1), 14(3)

The obligation

Notify any actively exploited vulnerability, and any severe incident affecting the product's security, simultaneously to the CSIRT designated as coordinator and to ENISA, via the Single Reporting Platform.

What Skarp CRA does

This obligation triggers on becoming aware, and the daily SBOM scan is one of the ways you do: your components are checked against CISA's Known Exploited Vulnerabilities catalogue, and a match is flagged as exploited and mailed to everyone on the product. A feed match is a candidate, never a record — version ranges over-match, and opening an incident from one would put a spurious notification in front of a CSIRT. Confirming it is the act that starts the clocks, and it will not accept a confirmation without a rationale saying what you checked. Awareness then anchors on when the tool told you rather than on when you got round to confirming, so a slow response cannot quietly understate how long you had known. Marking any vulnerability actively exploited does the same thing; a severe incident can be opened directly. The tool never submits anything — you file on the Single Reporting Platform under your own EU Login, and record the submission reference here afterwards. Recording a submission is not a submission.

scan_advisories · confirm_advisory · record_vulnerability · update_vulnerability · report_incident · record_report_submission

14(2), 14(4)

The obligation

For a vulnerability: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident: the same 24-hour and 72-hour stages, and a final report within one month.

What Skarp CRA does

All stages are derived from when you became aware, never from when the tool was called; omitting the awareness timestamp anchors on now and says so in the response. The 14-day final report is anchored on the date a corrective measure became available, and does not materialise until you record one. The one-month final report is anchored on awareness rather than on the 72-hour notification — where the reading is ambiguous, the earlier deadline is the safe one. Status is derived from stored timestamps, so a sweeper outage cannot mark you compliant.

get_reporting_deadlines · update_vulnerability

14(2), 14(4) — content

The obligation

Each stage has required content: the Member States where the product is available, the nature of the exploit, corrective measures taken and available to users, severity and impact, and information about any malicious actor.

What Skarp CRA does

Drafts are produced in ENISA's own field layout. A draft always comes out — missing fields are listed beside it, never instead of it, because a report you cannot see is worse than one with holes you can.

draft_report · check_reporting_readiness

14(5)

The obligation

An incident is severe where it affects the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or could lead to malicious code being introduced or executed.

What Skarp CRA does

The severity call is yours. The tool records which kind you chose, because the two differ only in the final-report deadline and that difference is legal rather than cosmetic.

report_incident

14(6)

The obligation

The coordinating CSIRT may request an intermediate report on status updates.

What Skarp CRA does

Nothing. There is no intermediate-report stage; attach the report you sent as evidence.

14(7)

The obligation

Notifications go to the CSIRT of the Member State of your main establishment, via one of the platform's electronic notification end-points; where there is no main establishment in the Union, a fallback order determines which.

What Skarp CRA does

The rule is stated and the Member States where your product is available are recorded, since that is an obligatory report field. The tool does not name your CSIRT: the platform routes on the registration details you give it, so the answer is settled when you register, not per report.

get_applicable_csirt · set_submitter_profile

14(8)

The obligation

After becoming aware, inform the impacted users of the vulnerability or incident and, where necessary, of the mitigation and corrective measures they can deploy.

What Skarp CRA does

Nothing. This runs in parallel with the CSIRT clocks and is easy to lose behind them; attach what you sent as evidence.

Fourteen properties of the product itself: the software either encrypts data at rest or it does not, and no compliance tool changes that. For twelve of them the honest ceiling is the same — the tool records whether your assessment makes the requirement applicable and why, holds the evidence that the engineering happened, hashed with its provenance, and reports a gap in the technical file until it is there. It cannot make the software behave this way, and a tick against one of these means only that somebody attached a document. What it does do is put the requirement, and the risk from your own assessment that triggered it, in front of the agent writing the code. The two rows where the answer is different are I(1) and I(2)(a). Evidence is tied to the release it describes, because these requirements attach to the product *as placed on the market* — a test report proves something about one build. Record a new release and anything evidenced only against an earlier one reports as stale and stops the technical file reporting it settled. Evidence carrying no release at all is reported as unversioned rather than stale: the tool does not know which build it describes, and saying so beats guessing.

Annex I Pt I(1)

The obligation

Designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks.

What Skarp CRA does

The risk assessment this requirement is judged against is the one your agent drafted from your codebase and you confirmed. Whether the resulting engineering is appropriate is a judgement no tracker makes — the tool holds the assessment, the decisions and the evidence.

confirm_risk_assessment · attach_evidence

Annex I Pt I(2)(a)

The obligation

Made available on the market without known exploitable vulnerabilities.

What Skarp CRA does

The one Part I requirement with a mechanism rather than an evidence slot. Your SBOM is checked daily against the OSV database — every advisory affecting a component you ship, not only the exploited ones — and separately against CISA's Known Exploited Vulnerabilities catalogue, which flags the subset known to be under attack. Severity is carried through from the advisory where it has one and left blank where it does not, because a fabricated score on a compliance record is worse than no score. Every match is a candidate you work to a disposition, and a dismissal needs a VEX justification — that the vulnerable code is not in the execute path, cannot be controlled by an adversary, or is already mitigated. Each of those is a statement that the vulnerability lacks the potential to be effectively used under practical operational conditions, which is the Article 3(41) test this requirement turns on, so the record of having worked a candidate is the evidence the product shipped without a known exploitable vulnerability. Note the distinction: KEV lists what is actively exploited, which is a narrower set than exploitable, so a clean KEV result does not answer this requirement on its own. This requirement is about a moment — being made available on the market — so place_on_market is where it is answered. Placing a version checks that a scan actually ran, that it reached its feeds, that it is recent, and that no candidate is still unresolved, then freezes the result as evidence tied to that version. It refuses when the record cannot support the claim, which is not a finding that your product is affected. You can ship anyway with a written reason, and that reason is kept on the determination and in the audit trail. What is found afterwards does not make a shipped release non-conformant: that is Article 13(8) and Annex I Part II(2). Candidates are ordered by EPSS, the daily model of how likely a CVE is to be exploited in the next 30 days, so the queue is worked in an order that means something. There is no threshold anywhere: a cutoff would be a compliance policy dressed as a fact, and every candidate still needs a determination. Both numbers are shown, because probability alone misleads — 5% sounds negligible and can be the 92nd percentile among all scored CVEs. A CVE the model has not scored is shown as unscored rather than as a low score. If the predicted likelihood of something you dismissed rises materially, it comes back for a second look, carrying both the old and new figures. EPSS informs that judgement and never makes it: it cannot dismiss anything, and it is never on its own a reason to.

record_sbom · scan_advisories · confirm_advisory · dismiss_advisory · record_build · place_on_market

Annex I Pt I(2)(b)

The obligation

Secure by default configuration, including the ability to reset the product to its original state — unless otherwise agreed between manufacturer and business user for a tailor-made product.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(c)

The obligation

Vulnerabilities can be addressed through security updates, including automatic updates where applicable, with opt-out and the option to postpone.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(d)

The obligation

Protection from unauthorised access by appropriate control mechanisms, including authentication and access management, and reporting of possible unauthorised access.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(e)

The obligation

Confidentiality of stored, transmitted or processed data, such as by state-of-the-art encryption at rest and in transit.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(f)

The obligation

Integrity of stored, transmitted or processed data, commands, programs and configuration against unauthorised manipulation, and reporting of corruption.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(g)

The obligation

Data minimisation — process only data adequate, relevant and limited to what is necessary for the intended purpose.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(h)

The obligation

Availability of essential and basic functions, including resilience and mitigation against denial-of-service.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(i)

The obligation

Minimise the product's negative impact on the availability of services provided by other devices or networks.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(j)

The obligation

Limit attack surfaces, including external interfaces.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(k)

The obligation

Reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(l)

The obligation

Provide security-related information by recording and monitoring relevant internal activity, with an opt-out for the user.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Annex I Pt I(2)(m)

The obligation

Allow users to securely and permanently remove all data and settings, and to transfer data securely where that is possible.

What Skarp CRA does

Applicability recorded from your own risk assessment, evidence held by value with its provenance and tied to the release it describes, and a gap reported in the technical file until it is there.

Eight vulnerability handling requirements. These are a process rather than a property, which is why more of this section can be carried by tooling.

Annex I Pt II(1)

The obligation

Identify and document vulnerabilities and components, including a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies.

What Skarp CRA does

Both halves are done rather than recorded: the bill of materials is stored by value, and the daily scan is the identification half against it.

record_sbom · scan_advisories · list_advisory_candidates

Annex I Pt II(2)

The obligation

Address and remediate vulnerabilities without delay, providing security updates separately from functionality updates where technically feasible.

What Skarp CRA does

Vulnerability records carry status and a remediation reference, and confirmed advisories become records to work. The remediation is engineering; the tracking is here. There is no clock on "without delay" — unlike Article 14, the regulation sets no deadline, which is exactly why it drifts.

record_vulnerability · update_vulnerability · confirm_advisory

Annex I Pt II(3)

The obligation

Apply effective and regular tests and reviews of product security.

What Skarp CRA does

Evidence only. A single test report satisfies the checklist indefinitely: the requirement says effective and regular, and cadence is not modelled.

attach_evidence

Annex I Pt II(4)

The obligation

Once a security update is available, publicly disclose information about fixed vulnerabilities — description, affected versions, impact, severity, and how users remediate.

What Skarp CRA does

Nothing. The tool holds every input — the vulnerability, the affected component, the fix reference, the severity — and the dismissal path already produces VEX for not affected, but the affected and fixed advisory is not generated.

Annex I Pt II(5)

The obligation

Put in place and enforce a coordinated vulnerability disclosure policy.

What Skarp CRA does

The policy URL is recorded and surfaced by the readiness check before an incident rather than during one. It is never fetched, so a URL that 404s satisfies the field and not the requirement.

set_submitter_profile · check_reporting_readiness

Annex I Pt II(6)

The obligation

Facilitate sharing of information about potential vulnerabilities, including a contact address for reporting vulnerabilities found in the product.

What Skarp CRA does

The security contact address is recorded alongside the disclosure policy.

set_submitter_profile

Annex I Pt II(7)

The obligation

Provide mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely and, where applicable, automated manner.

What Skarp CRA does

Evidence only. The security of your update channel is a property of the channel.

attach_evidence

Annex I Pt II(8)

The obligation

Disseminate security updates without delay and free of charge, with advisory messages telling users what action to take.

What Skarp CRA does

Evidence only. Dissemination and the advisory messages that accompany an update happen outside the tool.

attach_evidence

The eight sections the technical file has to contain. Assembled as a gap report first — what is missing matters more than the prose — and freezable with a content hash once it is complete.

Annex VII(1)

The obligation

General description of the product

What Skarp CRA does

Assembled from what you recorded about the product — its intended purpose, where it runs, and the class you settled. Annex II user information is one line here, satisfied by attachment.

classify_product · attach_evidence

Annex VII(2)

The obligation

Design, development, production and vulnerability handling processes

What Skarp CRA does

Evidence, attached against the processes it describes.

attach_evidence

Annex VII(3)

The obligation

Cybersecurity risk assessment

What Skarp CRA does

Filled from the confirmed assessment itself, not a summary of it. The slot does not report complete while the assessment is a draft or has gone stale.

confirm_risk_assessment

Annex VII(4)

The obligation

Support period determination

What Skarp CRA does

Filled from the Article 13(8) determination rather than an attachment. It completes only when both the dates and the reasoning are recorded, because the reasoning is what this section is for.

set_support_period

Annex VII(5)

The obligation

Standards and specifications applied

What Skarp CRA does

Recorded as evidence. The standards listed here are not monitored for change — see 13(14).

attach_evidence

Annex VII(6)

The obligation

Test reports

What Skarp CRA does

Test reports attached as evidence, hashed with their provenance.

attach_evidence

Annex VII(7)

The obligation

EU Declaration of Conformity

What Skarp CRA does

Generated from the frozen file and bound to its content hash.

generate_declaration_of_conformity

Annex VII(8)

The obligation

Software bill of materials

What Skarp CRA does

Filled from the bill of materials you recorded, stored by value.

record_sbom

Reconciled against the published text on 2026-08-06 (oldest of the catalogue files). The summaries are still paraphrases, not quotations — cite the link for authoritative wording. Article 7(4) delegated acts can amend the annexes, so this is true as of that date.