What the CRA is, in one paragraph
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for "products with digital elements" sold in the EU: software and hardware, including the software that runs a website. Manufacturers must design products securely, know what components they contain, handle vulnerabilities for the product's support period, and report actively exploited vulnerabilities and serious incidents within tight deadlines. NIS2, the directive alongside it, pushes the same expectations down supply chains: an organisation in scope has to show that the suppliers it depends on, including whoever builds and runs its website, manage security properly.
This guide is not legal advice. It is the working checklist we use for WordPress sites, written so that each item produces something you can hand to an auditor rather than a box you ticked.
Dates that matter
- 11 September 2026: the CRA's reporting obligations apply. Actively exploited vulnerabilities must be notified within 24 hours (early warning), 72 hours (notification) and 14 days (final report).
- 11 December 2027: the main obligations apply in full.
- NIS2 has been transposing into national law since October 2024. Member states differ on timing and scope, so check the country you operate in.
If you sell software to EU customers, or run sites for organisations that are in NIS2 scope, the paperwork era has started.
Who this applies to in a WordPress context
- Plugin and theme vendors are manufacturers of products with digital elements. Most of the CRA applies to you directly, including the SBOM and vulnerability-handling duties. Open-source stewards get lighter obligations, but a paid product is a product.
- Agencies that build and host sites for clients sit in the supply chain. Clients in NIS2 scope will ask you for evidence: an inventory, a patch policy, an incident process.
- Site owners in regulated sectors (energy, health, finance, digital infrastructure, public administration, and their suppliers) are the ones being asked. Everyone else benefits from the same hygiene without the legal pressure.
The checklist
Each item says what to do and what counts as evidence. Dragon Compliance automates the first two sections and records evidence for the rest; where it does, the tab is named.
1. Know what you run
- Maintain a software inventory: WordPress core, every plugin and theme with version, author and licence, plus the PHP, database and server versions. Evidence: the Inventory tab, exported on a date.
- Produce an SBOM on request: a Software Bill of Materials in a standard format. CycloneDX is what most enterprise buyers ask for; SPDX is the other. Evidence: the exported file. See generating an SBOM for WordPress.
- Remove what you do not use. An inactive plugin is still code on the server and still in your inventory.
2. Monitor for known vulnerabilities
- Check the inventory against a vulnerability database daily, not when you remember. Evidence: the Findings tab and the scan entries in the Evidence log.
- Define severity handling: what happens on a critical finding (patch or disable within 24 hours is a common policy), what happens on a low one. Evidence: a written policy, and the time between detection and resolution for each finding.
- Have an alert route that reaches a human. Email to the site admin at minimum. Evidence: alert configuration and a test alert.
3. Patch and prove it
- Auto-updates coverage: enable automatic updates for core minor releases and for plugins you trust, and record the reasoning for any you exclude. Evidence: the checklist item "auto-updates coverage" and the update entries in the Evidence log.
- Time to patch: measure it. Auditors ask for the median, not a promise. Evidence: Dragon Compliance Pro computes time-to-patch from the findings history.
- Backups before updates, and a tested restore. Evidence: a written backup policy attested in the checklist, plus a dated restore test.
4. Harden the obvious
These are the automatic checks in the Checklist tab. Each is a quick win with a clear pass or fail:
- HTTPS everywhere, with HTTP redirected.
- Debug mode off in production.
WP_DEBUGon a live site leaks paths and queries. - File editing disabled (
DISALLOW_FILE_EDIT), so a compromised admin account cannot turn the theme editor into a shell. - No default "admin" account.
- Two-factor authentication for administrators. Dragon Login Security adds TOTP, backup codes and passkeys, and the Pro edition can enforce it by role.
- No open critical findings.
5. Write the process down
The CRA and NIS2 are as much about process as controls. You need, in writing:
- A vulnerability disclosure policy: how someone reports a security issue to you, and how you respond. A page on your site and a security contact address is the minimum.
- An incident response plan with the 24-hour, 72-hour and 14-day reporting steps and who owns each.
- An update and support policy: how long you support what you ship, and how quickly you patch.
Evidence: the documents themselves, attested with a date in the Checklist tab so the attestation is logged.
6. Keep the evidence
An audit trail you can lose by uninstalling a plugin is not an audit trail. Dragon Compliance keeps its evidence log on uninstall by default; Pro adds a hash chain so a tampered entry is detectable. Export a report periodically and keep it with your other compliance records.
What auditors and enterprise buyers actually ask for
In practice, the questionnaire arrives as a spreadsheet and wants: a current SBOM, evidence of vulnerability monitoring with dates, your patch SLA and proof you meet it, your disclosure policy, and your incident process. If you can produce those five things in an afternoon, you are ahead of most of the market.
Where to go next
Start with the inventory and a first SBOM export, because everything else refers back to them. Then turn on daily monitoring and let the evidence log accumulate for a month before you attest to anything. A policy you wrote yesterday with no history behind it is the weakest document in the pack.