ENISA's 2026 cybersecurity report: what its patching findings mean for CRA app teams
· 5 min read · CRA news
In short: ENISA's second State of Cybersecurity in the Union report, released on 10 November 2026, says the bottleneck is no longer finding vulnerabilities but handling them: triage, disclosure and fixing.
- It is a policy and maturity report, not a new rule. It does not change a single CRA deadline.
- It reports that 45% of surveyed IT service providers took more than three months to apply critical patches.
- For app teams the lesson is practical: the CRA's 24-hour clock only works if your fix pipeline is fast too.
What ENISA published
The EU cybersecurity agency released the second edition of its Report on the State of Cybersecurity in the Union, covering July 2024 to July 2026. We could not open the report itself from our tools, so the figures below come from two independent write-ups that cite it: a research note from the Cloud Security Alliance, which says it did not verify the numbers against the original, and a Help Net Security article of 11 November. Where only one of them gives a number, we say so. Check the PDF on ENISA's site before quoting any figure.
The headline: handling beats discovery
According to both summaries, ENISA argues that triage, prioritisation, coordinated disclosure and remediation are now bigger bottlenecks than discovery, and expects frontier AI to cut discovery time from days to hours. The CSA note adds that the window between disclosure and weaponisation is described as approaching zero. Help Net Security reports that 45% of surveyed IT service management providers took more than three months to apply critical patches to critical systems, and that 43% ran no cybersecurity assessment over a full year. Those are service providers, not app makers, but the pattern is familiar: finding the problem is quick, shipping the fix is slow.
What it says about the CRA
Both summaries repeat the dates app teams already know: reporting obligations have applied since 11 September 2026, and the regulation applies in full from 11 December 2027. Help Net Security adds that once a fix or mitigation exists, notified vulnerabilities are published in the European Vulnerability Database, with the manufacturer's agreement. The CSA note reports two ENISA recommendations: speed up the operational rollout of vulnerability-handling requirements, and make the Single Reporting Platform interoperable with other EU vulnerability services. It also says ENISA sees certification, possibly under EUCC, as one route to a presumption of conformity under Article 27. We did not see that point in the second summary, so treat it as a single-source report.
One more CSA-reported figure is relevant to the bigger picture: countries with no coordinated vulnerability disclosure policy, or one still in draft, fell from 17 to 7. National CVD policies are maturing, and that means reporters will increasingly know where to send findings, including to you.
Why a patch-speed report matters for the CRA clock
Article 14(2) of the CRA, as reproduced on cyberresilienceact.eu, asks for an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Article 13(8) ties vulnerability handling to the support period, at least five years unless the product is expected to be used for less.
| CRA step | What ENISA's findings suggest to check |
|---|---|
| Early warning, 24 hours | Who decides that a report shows active exploitation, and can they act on a weekend? |
| Notification, 72 hours | Can you name the affected app versions and the SDK or library involved? |
| Final report, 14 days after a fix | Can you build, test, sign and release a fix, or a mitigation such as a server-side switch, inside that window? |
| Support period | Do you know which old versions users still run, and which you can still patch? |
The deadlines run from when you become aware, and the final report from when a fix or mitigation is available, so a slow release cycle lengthens your exposure but does not stop the first two clocks. That reading is ours.
What mobile teams face in particular
App store review and staged roll-outs add days that a web service does not have, and users update at different speeds. Fixes in third-party SDKs depend on a maintainer. A realistic plan therefore combines three things: a way to ship a fix quickly (including expedited review where the store offers it), a way to mitigate without a release (feature flags, server-side kill switches, disabling a vulnerable code path), and a clear list of the components in each shipped version so that you know within minutes whether a new advisory affects you.
What we would do this week
- Measure your own time from a security report to a signed, released build, last time you did it. If you have never measured it, run a drill on a low-severity issue.
- Write down who is on call to decide that a vulnerability is actively exploited, and who files on the Single Reporting Platform.
- Keep an SBOM per released version, so triage starts from a lookup and not from a guess.
- List the mitigations you can switch on without a store release.
- Check that your security contact is published, so that reports reach you early.
- Prepare the advisory you will publish once a fix ships, so it does not slow the release: our security advisory generator drafts one.
Triage is faster when you know what is in each build. Generate an SBOM and see known vulnerabilities in seconds.
Open the free scannerSources
- Cloud Security Alliance: ENISA's 2026 State of the Union research note (publication date, findings, CRA recommendations).
- Help Net Security: EU cyber scores look healthy, but 45% of surveyed IT providers take months to patch (11 November 2026).
- ENISA: 2026 Report on the State of Cybersecurity in the Union (PDF; the primary document, which we could not open for this article).
- Regulation (EU) 2024/2847 (Cyber Resilience Act), full text on cyberresilienceact.eu: Articles 13(8), 14 and 27.
This article summarises two secondary reports on an ENISA publication and EU law for practical use; figures were not checked against the original report. It is not legal advice. Related: CRA vulnerability reporting for app teams · The CRA support period for apps · Reporting deadlines tool