EN 
AI Summary
- Under the EU's Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, manufacturers must provide security advisories informing impacted users about issues and corrective or risk-reduction steps.
- Since 11 September 2026, actively exploited vulnerabilities and severe incidents must be reported within 24 hours, followed by full notification within 72 hours. Final reports are due within 14 days of a vulnerability fix or one month of severe-incident notification.
- From 11 December 2027, manufacturers must publicly disclose fixed vulnerabilities, ship security updates with advisory messages, and maintain a coordinated vulnerability disclosure policy. Advisories may use formats such as security pages, knowledge bases, release notes, email, in-app banners, or CSAF.
- Actionable advisories should state affected products, severity, impact, technical details, mitigation steps, fixes, and next updates, serving both technical readers and executives.
- Before publication, security experts should verify accuracy, ensure engineers can identify affected versions and apply the fix, and confirm non-technical readers understand the incident and required action.
AI-generated content. It may contain errors.
See Document360 in action
When attackers exploit a vulnerability in a product, or a security incident affects its availability or data, customers need a clear advisory that tells them whether they’re affected and what to do. Under the EU’s Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, that advisory is now a legal requirement, not a courtesy.
Since 11 September 2026, manufacturers of connected hardware and software have been required to report actively exploited vulnerabilities and severe incidents within 24 hours, and send a full notification within 72 hours. The final report is due within 14 days of a fix being available for a vulnerability, or within one month of the notification for a severe incident.
Under Article 14(8), they must also inform impacted users about the issue and the steps they should take. With deadlines this tight, the advisory needs to be accurate, clear and ready to publish fast.
This blog covers what the CRA requires in a security advisory, what an actionable advisory should include, how to write it for both technical and non-technical readers, and how to review it before publishing.
What the CRA requires, and what it leaves to you
Under the CRA, informing users matters just as much as informing regulators. Article 14(8) requires manufacturers to tell impacted users about the issue and the corrective or risk-reduction steps they can take. Alongside the human-readable advisory, technical writers can also publish it in CSAF (Common Security Advisory Framework), a machine-readable format that security tools can process automatically.
From 11 December 2027, the CRA’s vulnerability handling requirements in Annex I, Part II also apply. Manufacturers must:
- Publicly disclose fixed vulnerabilities, with a description, affected products, impact, severity and clear guidance to help users fix them.
- Ship security updates with advisory messages that tell users what action to take.
- Have a coordinated vulnerability disclosure policy in place.
The CRA defines what an advisory must cover, but not how it should look. It sets no rules on structure, headings or format, and doesn’t say where to publish it. Manufacturers can use a security page, a knowledge base article, release notes, email or an in-app banner. Regulator reports follow fixed stages, but the user advisory can be updated as more is learned.
What Every Actionable Security Advisory Should Include
A good security advisory answers the reader’s most urgent questions first, in this order:
- Am I affected?
- How severe the security issues are?
- What should I do now?
- What happens next?
The core elements of the report should cover the following areas
1. Executive Summary
- Headline: the product name, type of issue and severity. For example, “Critical: Authentication bypass in [Product name] version [x.x]”.
- Advisory details: advisory ID, first published date, last updated date, author and contact details.
- Short overview: a few sentences on the issue, its impact and the one action users must take.
2. Vulnerability and Exploitation Details
- The vulnerability being exploited, stated clearly to show urgency.
- Its severity and risk level.
- Technical details of the vulnerability and how it was exploited.
- All affected areas, such as authentication, functionality, UI, data security and APIs.
- Root cause analysis (RCA) findings, if available.
3. Impact on Users
- In plain words, what an attacker could do, or has already done if the vulnerability was exploited.
- Technical details of how the system was compromised.
4. Mitigation and Next Steps
- Clear steps users must take, such as changing passwords, revoking API tokens or rotating security keys.
- What the manufacturer has already fixed, if anything.
- What users should do next and when to expect further updates.
Schedule a demo with one of our experts to take a deeper dive into Document360
Book A Demo
Writing for Both Security Teams and Executives
Every security advisory has two audiences: security specialists and C-level executives. That means a technical writer can’t write a purely technical report, and can’t rely on plain language alone either. The goal is one advisory that serves both readers, without splitting it into two documents.
The executive summary is written for C-level executives and IT admins who are responsible for software security. The sections that follow give security teams the technical depth they need.
Another useful technique is to state the consequence first and the technical cause second. For example: “Attackers can access customer data without logging in. This is caused by an authentication bypass in the login API.”
How to Review an Advisory Before Publishing
Security experts must review every security advisory before it’s published. Use these three checks to confirm it’s ready:
- Accuracy: A security expert has confirmed that the technical details, severity and fix are correct.
- Engineer test: Any engineer who reads the advisory can find the affected versions and apply the fix as described.
- Executive test: A non-technical reader can read the executive summary and understand what happened, how serious it is and what to do.
If the advisory passes all three checks, it meets the quality standard.
Final remarks
The CRA has made the security advisory a legal requirement for manufacturers of software and connected devices sold in the EU. Technical writers need to work closely with security teams to produce advisories that are accurate, clear and useful.
The CRA deadlines are strict, so writers will often work under time pressure. AI assistants, guided by a skills file, can help writers understand the security team’s root cause analysis (RCA) and turn it into a draft advisory faster.
After a thorough review, publish the advisory in the right place and share it with users through the right channels, such as email, your website or in-product notices.
