PRGuard
Get started →

Assurance · Cyber Resilience Act

The Cyber Resilience Act, Requirement by Requirement.

The Cyber Resilience Act puts security duties on whoever makes software or connected products available in the EU, sold or free, in the course of business, for as long as they support them. PRGuard keeps the evidence for how that product’s code is written, reviewed and fixed, automatically, as you ship. Here is how it helps, requirement by requirement, with each linked to the law’s own text.

Watch the overview Go requirement by requirement
The video’s words

The Cyber Resilience Act puts security duties on anyone who makes software or connected products available in the EU, for as long as they support them. So what can PRGuard show for it?

Halcyon supplies its SDK to merchants across the EU, so it treats the SDK as its product under the Act, and itself as the manufacturer.

The Act asks for a product built securely, shipped without known vulnerabilities, with vulnerabilities fixed without delay and its security reviewed regularly.

Each change to the SDK is audited against Halcyon's security rules, and the record shows what became of every one.

When a change shipped with a finding open, the record says so, and what happened next.

An accepted risk has a reason, an approver who did not ask for it, and an end date.

At the end of the quarter, it is one evidence pack, ready for whoever asks.

PRGuard Assurance keeps the evidence of a secure development process, change by change, ready for the day you are asked.

Halcyon Payments is a fictional company. It treats the SDK it supplies to merchants across the EU as its product under the Act.

Overview

What It Asks. How PRGuard Helps.

The Act asks a manufacturer to design and build a product securely and to ship it without known exploitable vulnerabilities, then, for as long as the product is supported, to fix vulnerabilities without delay and test and review its security regularly.

PRGuard sits where your product’s code changes. It audits each change against your own rules, security rules included, and records what happened to every change that reached a default branch: what was found, when it was fixed, who approved it, and what risk was accepted, by whom and until when. When the quarter ends, that record is one file your assessor checks on their own machine.

That record is your strongest evidence for regular security reviews, and adds evidence, for the code, toward secure development, shipping without known exploitable vulnerabilities and fixing them without delay. Beside it sit the parts of the Act that belong to your wider process, such as the software bill of materials and reporting to the authorities.

  1. Annex I, Part I (1)Designed, developed and produced with appropriate cybersecurityCovers the code
  2. Annex I, Part I (2)(a)Made available without known exploitable vulnerabilitiesCovers the code
  3. Annex I, Part II (2)Vulnerabilities are addressed and remediated without delayCovers the code
  4. Annex I, Part II (3)Regular security tests and reviewsStrongest fit

Before you start

Who, Which and When.

Who the rules are for

Most duties fall on the manufacturer: whoever develops or manufactures a product with digital elements, or has one made, and markets it under their own name or trademark (Article 3(13)). Importers and distributors have their own (Articles 19 and 20).

The duties stay with you as the manufacturer, which is why the evidence matters. PRGuard is a tool you build with: it gathers that evidence for you as you work.

Which products

Software and hardware products made available in the EU that connect, directly or indirectly, to a device or network, with their remote data processing (Articles 2 and 3). Some sectors, such as medical devices and vehicles, are covered by their own laws. A service delivered purely online is outside it unless it is the remote data processing of such a product.

Most products are assessed by their own manufacturer. Those the Act lists as important (Annex III) or critical (Annex IV) have stricter checks. Whether yours is in scope is a judgement for you and your advisers.

When they apply

Since 11 September 2026, manufacturers report actively exploited vulnerabilities and severe incidents (Article 14). The security requirements and most of the rest apply from 11 December 2027 (Article 71); the rules for conformity assessment bodies already apply, from 11 June 2026.

A product already on the market before then has to meet the security requirements only once it is substantially modified (Article 69). The reporting duty applies to it either way.

A quarter of evidence takes a quarter to gather, so the time to start keeping it is before the date.

Requirement by requirement

Four Requirements. What Each Asks.

The Annex I requirements Readiness tracks for the Act: what each asks, and how PRGuard helps you show it.

Annex I, Part I (1)

Designed, developed and produced with appropriate cybersecurity

Covers the code
The video’s words

The Act asks that a product is designed, developed and produced with an appropriate level of cybersecurity. Development happens one change at a time, and PRGuard is there for each one.

Halcyon's secure development rules live in a rule file, mapped to this requirement. Readiness shows the audits that ran with it.

Each change to the SDK is audited against them before it merges: who wrote it, how it was checked, and what became of each finding.

PRGuard Assurance shows your secure development process at work, change by change, not only on paper.

What the Act asks

Products with digital elements are designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks.

How PRGuard helps

Secure development happens one change at a time, and PRGuard is there for each one.

Each change to the product’s repositories is audited against your rules, security rules included, before it merges. Map the rule files that hold your secure development standards to this requirement, and Readiness shows the audits that ran with them.

Who or what wrote each change, how it was checked and what became of each finding are on the record, so you can show your process at work, not only describe it.

Where you see itCoverageReadiness

What stays with you

The product’s cybersecurity risk assessment and its design as a whole, such as secure defaults, access control and data protection. PRGuard brings the evidence from the code.

Annex I, Part I (2)(a)

Made available without known exploitable vulnerabilities

Covers the code
The video’s words

The Act asks that a product is made available without known exploitable vulnerabilities. A vulnerability caught in review can be fixed before it reaches a release.

PRGuard audits each change for the vulnerabilities in your security rules. This one was caught, fixed, and only then merged.

And if a change merges with a finding open, the record says so, with what happened next.

Your dependency scanner watches the components you ship. PRGuard watches the code you write.

What the Act asks

On the basis of the cybersecurity risk assessment and where applicable, products are made available on the market without known exploitable vulnerabilities.

How PRGuard helps

A vulnerability caught in review can be fixed before it reaches a release.

PRGuard audits each change for the classes of vulnerability in your security rules, such as injection or broken access control, before it merges. A change that merges with a finding open is on the record, with what happened next: fixed, or accepted as an exception with an approver and an end date.

PRGuard also looks up each package version a change sets in its manifests and lockfiles in the OSV.dev vulnerability database. A version with a known vulnerability is a finding on that change, in the database’s words, and an error when the vulnerability is rated high or critical and a fixed version exists.

Where you see itCoverageExceptions

What stays with you

Components already in your product before PRGuard was connected, whether your code reaches the vulnerable part of a component, and the software bill of materials for what you ship. PRGuard covers the code you write and the versions each change sets.

Annex I, Part II (2)

Vulnerabilities are addressed and remediated without delay

Covers the code
The video’s words

The Act asks that vulnerabilities are addressed and fixed without delay. For each one found in your code, PRGuard shows when it was found, and when it was fixed.

Found in one audit, fixed by the next, with the dates and the audits that link the two.

A finding your team chooses not to fix yet becomes an exception, with a reason, an approver who did not ask for it, and an end date.

When the date passes, the finding opens again, so no accepted risk is quietly forgotten.

Security updates and disclosure stay with you. PRGuard keeps the record for each vulnerability found in your code.

What the Act asks

In relation to the risks, vulnerabilities are addressed and remediated without delay, including by providing security updates.

How PRGuard helps

For each vulnerability PRGuard finds in your code, the record shows when it was found, when it was fixed and the audits that link the two.

A finding your team chooses not to fix yet becomes an exception, with a reason, an approver who is not the person who asked, and an end date. When the date passes, a finding closed under it opens again, so no accepted risk is quietly forgotten.

A package version with a known vulnerability is a finding when the change that sets it is audited, so moving to the fixed version is on the record too.

Where you see itCoverageExceptions

What stays with you

Vulnerabilities reported to you from outside, ones published later in components you already ship, your disclosure policy, and shipping security updates to your customers. PRGuard keeps the record for the ones found in your code and in the versions your changes set.

Annex I, Part II (3)

Regular security tests and reviews

Strongest fit
The video’s words

The Act asks for effective and regular reviews of a product's security. Regular review is exactly what PRGuard does, on each change, as you ship.

Halcyon's security rules are mapped to regular security reviews, and Readiness shows the audits that ran with them.

Each change to the SDK is on the record: how it was audited, what was found and what became of it. Even a change that slipped past the audit is accounted for.

When the quarter ends, it is one evidence pack your assessor verifies on their own machine.

PRGuard Assurance: regular security review on each change, with the evidence kept for you.

What the Act asks

Effective and regular tests and reviews of the security of the product are applied.

How PRGuard helps

This is where PRGuard fits best. Regular security review is what it does, on each change, as you ship.

Each pull request and push is audited against your security rules, and every change that reached a default branch is on the record: how it was audited, what was found and what became of it. Even a change that slipped past the audit is accounted for, with the reason. When the quarter ends, it is one evidence pack your assessor verifies on their own machine.

Where you see itCoverageReadinessPacks

What stays with you

Testing the product as a whole, such as penetration tests and tests of the running product. PRGuard covers the review of each change to its code.

In PRGuard

Set It Up in Five Steps.

  1. On the Assurance Settings tab, tick Cyber Resilience Act.

  2. In the scope grid, put in scope the repositories of the products you sell in the EU, and give every other repository its reason for being left out.

  3. Map your rule files to the requirements they support: your security rules to secure development, known vulnerabilities and regular reviews, your release standards to fixing vulnerabilities.

  4. Readiness for the Cyber Resilience Act then shows, over the repositories in scope, which requirements have a rule that audits ran with.

  5. When a quarter ends, an owner can sign it off, and an evidence pack carries the record.

The guide to Assurance, part by part

Scope

Evidence Your Assessor Can Use.

PRGuard gives you evidence that your process for writing, reviewing and fixing your product’s code was followed, gathered as you ship and ready to hand over. Whether the product conforms to the Act, which requirements apply to you and whether what you have is enough are judgements for you, your advisers and whoever assesses you; PRGuard does not make that call for you. This page explains what PRGuard records. It is not legal advice.

The law’s own text

Each requirement links to its place in the regulation’s text on EUR-Lex and to the European Commission’s summary of the Act. This page was checked against the text on 19 October 2026.

Keep the Record as You Ship.

Switch Assurance on and the last 90 days are read for you.

Start the $10 trial