iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A useful Cyber Resilience Act (CRA) evidence packet for a WordPress plugin is more than a release checklist: it is a maintained record connecting the product’s identity and market status to its cybersecurity risks, applicable requirements, components, vulnerability handling, updates and support period. Whether a particular plugin is covered depends on how it is supplied and whether it is made available on the EU market in the course of commercial activity; a plugin’s name or presence in a public repository does not settle that question.
The CRA’s reporting obligations began applying on 11 September 2026, while its general application date is 11 December 2027. Those are separate milestones, not one compliance start date. The core legal reference is Regulation (EU) 2024/2847.
Does the Cyber Resilience Act apply to a WordPress plugin?
Start the packet by recording facts that let the responsible manufacturer assess the plugin’s status. The title “WordPress plugin” is not enough to establish that the CRA applies. Relevant facts include the plugin’s intended purpose, how it is distributed, where it is made available, who makes it available, and whether that happens in the course of commercial activity.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesThe regulation distinguishes commercial supply from open-source software that is not made available in the course of commercial activity. Hosting software on an open repository, by itself, does not put it on the market: the Act says that “the sole act of hosting products with digital elements on open repositories, including through package managers or on collaboration platforms, does not in itself constitute the making available on the market of a product with digital elements.” That does not determine the status of any individual plugin. The Act’s examples of commercial activity include monetizing related services, requiring non-security personal-data processing as a condition of use, or receiving donations beyond cost recovery. Check the plugin’s actual arrangements against the regulation before treating a repository listing as either proof of coverage or proof of exemption.
#1 Best Overall
Record the conclusion and its factual basis, including who is acting as manufacturer. If those facts change—for example, the distribution or monetization model changes—the scope assessment may need to be revisited.
What goes in a CRA evidence packet for a software release?
The technical documentation should make it possible to trace the product’s risks to the cybersecurity requirements, the measures taken, and the evidence supporting those measures. A practical packet can use the following sections. The artifact names are a way to organize evidence; the regulation sets the obligations, not a particular folder layout.
Rank #2
| Packet section | What to record | Why it belongs |
|---|---|---|
| Product and scope | Plugin name and version, intended purpose, essential functions, deployment context, market destination, manufacturer, distribution method and scope conclusion. | These facts support the assessment of whether the product is made available on the Union market and who is responsible as manufacturer. |
| Cybersecurity risk assessment | The assessment for the product, its relevant risks and the reasoning behind the measures selected. | The risk assessment belongs in the technical documentation and informs how the essential requirements apply. |
| Requirements and applicability | A mapping of relevant essential cybersecurity requirements to the measures and supporting evidence; give a clear justification for any requirement treated as not applicable. | The technical documentation must contain relevant data or details of the means used to demonstrate compliance, including reasons where an essential requirement does not apply. |
| Components and vulnerabilities | A software bill of materials (SBOM) in a commonly used machine-readable format covering at least top-level dependencies; preserve the dependency inventory and the method and version used to generate it, along with relevant known vulnerabilities and remediation decisions. | Annex I, Part II requires manufacturers to identify and document vulnerabilities and components, including an SBOM at that minimum coverage. |
| Security review and tests | Records of security tests and reviews, with their scope, results and resulting decisions. | The manufacturer must conduct effective and regular security tests and reviews. |
| Vulnerability handling and updates | The coordinated vulnerability disclosure policy, a contact address for reports, vulnerability and remediation records, and evidence of secure update distribution. | The CRA addresses vulnerability disclosure, remediation without delay, security updates and secure update mechanisms. |
| Support period and user information | The support-period rationale and factors considered, support end date, vulnerability contact details, and instructions for secure use and security updates. | The manufacturer must determine and document the support period and provide relevant information to users. |
Keep the evidence proportionate to the product’s nature and cybersecurity risks. The regulation says manufacturers shall “systematically document, in a manner that is proportionate to the nature and the cybersecurity risks, relevant cybersecurity aspects concerning the products with digital elements, including vulnerabilities of which they become aware and any relevant information provided by third parties.” The provision is in Article 13(7) of the CRA.
How should the evidence connect the risk assessment to the release?
A collection of unrelated files is difficult to use. Give each identified risk and each applicable requirement a traceable path to the measure, the release evidence and any follow-up action. For example, a record might identify a risk, point to the security control intended to address it, link to the relevant test or review, and note whether the release passed or what remediation remains. This is a practical way to make the technical documentation intelligible; it is not a prescribed CRA template.
- Identify the product and version the evidence concerns.
- Link each risk to the requirement or requirements it affects and to the corresponding measure.
- Link measures to tests, reviews, component information or other evidence that supports the compliance claim.
- Record unresolved findings, remediation decisions and the release or update in which they were addressed.
- Give each record an owner or maintenance responsibility so it can be updated as the product changes.
This traceability helps distinguish what was assessed for a particular release from what remains part of the ongoing manufacturer process.
What must the technical documentation say about vulnerabilities and updates?
The packet should cover both the components in the plugin and the process for responding when vulnerabilities are found. Preserve the SBOM and how it was generated, document relevant known vulnerabilities and decisions, and retain records of security tests and reviews. Include how vulnerability reports are received, how they are handled and remediated, and how security updates are distributed securely.
The user-facing side matters too: the CRA calls for a coordinated vulnerability disclosure policy and a contact address for vulnerability reports. It also requires public information about vulnerabilities fixed by security updates, subject to a narrow provision allowing publication to be delayed where justified security risks outweigh the benefits. A packet should therefore connect the fix and release record to the applicable public information and any decision to delay it.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What support period should a plugin release document?
The manufacturer determines a support period that reflects the product’s expected use and reasonable user expectations, and documents the factors considered. The baseline is at least five years. If the product is expected to be used for less than five years, the support period corresponds to that expected use time. Do not treat five years as an automatic answer for every plugin; record the rationale for the period chosen.
Include the support end date and user information about the vulnerability contact, secure use and security updates. The technical documentation must be maintained as appropriate at least during the support period.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which CRA dates and reporting deadlines matter to a release packet?
As of 9 October 2026, the earlier reporting milestone has passed, but the general application date is still ahead. The European Commission distinguishes these dates in its CRA summary and reporting guidance.
| Date or deadline | What it means |
|---|---|
| 11 September 2026 | CRA reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security begin to apply. The Commission says these obligations also extend to products made available on the Union market before the general application date. |
| 11 December 2027 | The CRA’s general application date. |
For an actively exploited vulnerability, Article 14 sets an early warning without undue delay and within 24 hours of awareness, a vulnerability 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 sequence is a 24-hour early warning, a 72-hour incident notification and a final report within one month after the incident notification. These are statutory reporting windows; check the Commission’s current reporting instructions for implementation and platform details.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How should the packet be maintained after release?
Article 31 requires technical documentation to be prepared before the product is placed on the market and updated as appropriate, at least during the support period. The Official Journal text of Article 31 states: “The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.”
In practice, treat the packet as a versioned record rather than a one-time export. Tie changes to the plugin release they affect, retain updated component and vulnerability information, and revise the risk, requirements or support records when relevant product facts change. Assigning an owner for each part makes it clearer who updates it when code, dependencies, distribution arrangements or vulnerability-handling processes change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
