How do you inform users after a CRA vulnerability or incident?
Article 14(8) requires manufacturers to inform impacted users, and where appropriate all users, of an incident and of the mitigations they can deploy, while Annex I Part II point (4) requires manufacturers to publicly disclose information about a vulnerability once a security update is available. These are two different duties with different triggers. The first applies when an incident or actively exploited vulnerability is affecting users now. The second applies after a fix exists. The answer for your organization depends on the product, the size and location of its user base, whether a fix is available, and whether the risk is still live. Commission guidance C(2026) 5252 accepts that the Article 14(8) notice may be limited to affected users while risks persist, so the audience and timing of each message should be decided case by case and recorded. The decision on what to send, to whom and when belongs to your organization, and so does the advisory text. Your product security or PSIRT team should own the criteria, the approval path and the sign-off, with legal and communications reviewing wording before release. An implementation partner can help build the process, the notification templates, the distribution channels and a structured, machine-readable advisory format where your product supports it, but the partner does not decide what is disclosed. Confirm with your market surveillance authority or legal counsel how the Article 14(8) duty applies to your product before you finalize the process. If a CSIRT informs your users because you did not do so in time, that outcome is itself a compliance failure to plan against. For each event, decide whether a fix or only a mitigation exists, which users need the notice now, and whether publication should be delayed under the justified-case rule in Annex I Part II point (4). Keep a written record of that justification. Every security update must be made available without delay and, unless a tailor-made product was agreed otherwise, free of charge, with advisory messages that explain what users should do. Confirm the exact fields your advisories must carry with the Commission FAQs and the guidance annex, and plan the handover to ENISA for the European vulnerability database under Article 17(5). Only an independent body or the regulator judges conformity; your records and advisories are the evidence they will review.
What the advisory process looks like from detection to publication
The sequence turns a confirmed vulnerability or incident into notices that reach affected users first, then a fix, then a public record that other customers and ENISA can act on. Each step produces a specific artifact so the manufacturer can show what it did and when.
Confirm which users are affected
The product security lead, working with engineering and the customer success or licensing team, identifies which installed versions, deployments, configurations and user groups are exposed. Compare the affected scope against the product inventory and any SBOM data so the list is based on evidence, not assumption. The output is a dated register of impacted users or customer tenants, with the basis for each inclusion. The step is complete when someone other than the author has reviewed the register and no affected group remains unassigned.
Prepare the mitigation message
Draft the notice that tells impacted users about the incident or vulnerability and what they can do now, such as applying a workaround, disabling an affected feature or changing a configuration. Article 14(8) asks for information on mitigations users can deploy, and where practical a structured, machine-readable format, so agree the format with the team that will publish it. Legal, product and security sign off on the wording before it leaves the company. The output is an approved notice with its version, audience and mitigation steps recorded in the case file.
Issue the notice to affected users
Send the approved notice to the impacted users identified in the register through the channels you already use for security communications, such as account contacts, tenant admin consoles or direct email. Record the send time, the recipients and any bounces or unreachable contacts, then follow up on those contacts through a second channel. Commission guidance distinguishes this duty to inform users, which may be limited to affected users while risks persist, from the later public disclosure. The output is a send log showing who was informed and when.
Release the security update
Ship the fix or, where a full patch is not yet possible, the interim mitigation, through the update channel that the product already uses. Annex I Part II point (8) requires security updates to be disseminated without delay and, unless agreed otherwise with a business user for a tailor-made product, free of charge, with advisory messages that explain relevant information and any action to take. Confirm the release reaches the affected versions and that the update's integrity checks work. The output is a released build, its release notes and a deployment check showing adoption across the affected population.
Publish the vulnerability description and remediation guidance
Once the update is available, publish the information Annex I Part II point (4) requires: a description of the fixed vulnerability, identifiers for the affected products, the impacts, the severity and clear remediation information for users. Decide, with documented justification, whether any delay is needed so users can apply the patch first, because point (4) allows delay only where the risks of publication outweigh its benefits. Confirm the published text matches the internal record. The output is a public advisory with a stable URL and a version history.
Share with ENISA and the European vulnerability database
Where the vulnerability was notified under Article 14(1) or Article 15(1) and is publicly known, check whether a fix or mitigation is available and agreed with the manufacturer, since ENISA adds such vulnerabilities to the European vulnerability database under Article 17(5) on that basis. Keep the advisory identifiers consistent with those in the notifications already filed through the reporting platform. The output is a short record confirming the advisory reference, the notification references and the status of any database entry.
Close the case and record lessons
Confirm that impacted users were informed, the update reached the affected population, the public advisory is live and any regulator or CSIRT communications are recorded. Document the root cause, the decision points on delay and scope, and the gaps found, then assign owners for each follow-up. The output is a closed case file with timestamps, approvals and the post-incident review, which becomes evidence of how the process operated during the support period.
When can public disclosure be delayed, and what must be recorded
Annex I Part II point (4) lets a manufacturer hold back publication of a fixed vulnerability only in duly justified cases. Each card below covers one part of that test, from the reasoning that justifies a delay to the point where it must end.
The point (4) allowance
Point (4) permits a delay only where the manufacturer considers that the security risks of publication outweigh the benefits, and the purpose of the delay is to let users apply the patch first. The allowance is narrow. It does not cover commercial convenience, release scheduling or a wish to avoid scrutiny. Check that your reason is about protecting users during patch uptake, not about your own timetable.
Documented reasoning for each delay
A justified case needs written reasoning that states the vulnerability, the users and products affected, the risk of publishing now, the benefit of publishing later, and why the balance tips toward delay. Record the evidence used, such as exploitation indicators, exposure counts or the availability of a fix. An illustrative record that says only that disclosure is risky would not show the balance test was performed.
Who approves the delay
Decide in advance who may approve a delay, usually a named senior role in product security together with legal or compliance, and record that approval with a date. Make sure the approver is not the engineer who wants the release shipped. Keep the approval attached to the vulnerability record so an assessor or market surveillance authority can trace the decision from discovery to publication.
Setting the end of the delay
A delay must end once users have had the chance to apply the patch. Define that point before the delay starts, for example when the update is released to all supported channels and advisory messages have gone out. Set a review date and confirm with your own customer data when most users have updated. Do not leave a delay open without an end condition or a review.
Delay is not a default
Treating delay as the standard route for every fixed vulnerability would conflict with the duty to publish after a security update is available. Review your delay log for patterns, such as the same product or team repeatedly invoking the allowance. If most fixes are held back, your process is likely failing the point (4) test and the records will not support it.
Records to keep for assessors
Keep the reasoning, approval, start and end dates, the patch release date, the publication date and the advisory text in one traceable record per vulnerability. Confirm with your legal team how long these records must be kept and where they are stored. An auditor or market surveillance authority will ask for this trail, and reconstructing it after the fact is hard to defend.
Does every vulnerability need a patch?
The Cyber Resilience Act does not oblige a manufacturer to ship a patch for every vulnerability found during the support period. Commission CRA FAQ 4.3.1 makes clear that the remedy depends on the risk the vulnerability creates for users. For a manufacturer of a self-hosted platform, that means the question is not whether a fix exists but which response protects users best in their actual deployments. Possible remedies include an immediate patch, a workaround advisory, updated manuals, or configuration guidance that disables the affected feature until a fix is ready. The Commission FAQs on the Cyber Resilience Act, version 1.4 set out this position and are the natural starting point for your team.
Document the risk decision behind each remedy. For every triaged vulnerability, record the affected components and configurations, the exploitability and severity you assessed, which users are exposed, and why you chose a patch, an advisory, a documentation update or a feature-disabling configuration. Link the record to the vulnerability handling file so an assessor or market surveillance authority can follow the reasoning from report to remedy. Confirm with your legal and security leads whether the same record should also feed the Article 14 notification decision, since the same facts often drive both.
Ask your implementation partner to build a template for this record before the first real case arrives, and check that your deployment tooling can identify which installations run a vulnerable configuration. A workaround is only useful if affected customers can find it and apply it. Test that the configuration change you recommend actually removes the exposure in a staging copy of your environment, and keep the test result with the decision record. Confirm the exact support period and update obligations for your product class with the Commission guidance and your national authority before you commit to a remedy that relies on a non-patch measure.
Who informs users: the manufacturer, the CSIRT or both
This is the default path. The manufacturer owns the duty under Article 14(8) of the Cyber Resilience Act to inform impacted users of the incident and of the mitigations they can deploy, and where appropriate all users. The notice is the manufacturer's own communication, issued from its own channels, and it should be ready before the early warning goes in, because the reporting clock runs at the same time. The manufacturer decides the content, the audience and the format, including whether a structured machine-readable format is appropriate for the affected product. Nobody else writes this notice for the manufacturer.
- Owner of the notice: the manufacturer, through its own support, security or product channels, not the CSIRT or ENISA.
- Audience: impacted users first, and all users where the mitigation applies more broadly.
- Content: what happened, which products and versions are affected, and the mitigations users can deploy now.
- Format: plain-language advisories, with a machine-readable version where that suits the product and its users.
- Timing: issued as soon as the mitigation is clear enough to act on, and kept current while risks persist.
Confirm with your legal and product security leads who signs the notice, which channels reach your installed base, and how you reach users with no account relationship with you.
If the manufacturer does not inform users in time, a CSIRT may do it instead. Article 14(8) allows the CSIRT to inform users when the manufacturer has not done so in a timely way. This is a fallback, not a transfer of duty. The manufacturer remains responsible for the failure, and a CSIRT notice does not replace the manufacturer's own obligations to its customers, its contract terms or its reporting to authorities. Treat the fallback as a reason to have your notice ready, because a CSIRT notice may describe your product in terms you did not choose.
- Trigger: the manufacturer has not informed impacted users in time, as judged by the CSIRT.
- Result: users may hear about the incident from the CSIRT rather than from you.
- Accountability: the reporting and notification failure stays with the manufacturer.
- Coordination: keep the CSIRT informed of the notice you plan to issue, so both messages match.
- Exposure: the enforcement consequences of a late or missing notice are a separate matter for the market surveillance authority.
Confirm with your counsel how your notification timeline is documented, so you can show when awareness started and why each notice went out when it did.
When a vulnerability sits in a third-party or open-source component you integrate, the user-facing notice still belongs to you as the manufacturer of the product. Your customers buy and deploy your product, not the upstream library, so they look to you for the advisory and the update. The upstream maintainer may publish its own fix or advisory, and you may coordinate with it, but that does not remove your duty to tell users how the affected product is exposed and what they should do. Your advisory has to name your product and versions, not only the upstream project.
- Ownership: you own the notice for your product even when the flaw sits upstream.
- Upstream role: the maintainer may publish its own advisory, which you can link to but should not rely on alone.
- Scope: your advisory names the affected builds of your product and the configuration that makes them exposed.
- Updates: users receive your security update, delivered free of charge with advisory messages, unless a tailor-made agreement says otherwise.
- Reporting: whether the flaw itself must be notified under Article 14 depends on its status and your role, which a separate page covers.
Confirm with your supplier and open-source contacts how they will inform you early, so your advisory is ready when the fix lands.
What to have ready before an incident happens
Informing users is only fast if the manufacturer already knows who the users are, how notices will be written and who can approve a disclosure or a delay. The five items below are the pre-work that makes Article 14(8) notices and Annex I Part II point (4) disclosures possible within the timelines that apply to a live event.
User contact register by product and version
Maintain a register that maps every deployed product, version and build to the customers, business users and contact channels that run it. For each entry, record who receives security notices and whether the contact is a named person or a shared mailbox. Check it by picking three sample products and confirming that a notice could reach every organization running them within a working day, using only the register. Gaps usually appear for embedded or self-hosted deployments, where the manufacturer may hold no direct contact.
Machine-readable notice template
Article 14(8) asks, where appropriate, for information to users in a structured, machine-readable format. Prepare a template that carries the product identifier, affected versions, a description of the incident, available mitigations and the date of the notice, and agree which format your users can ingest. Check it by generating a sample notice from a past test event and confirming that a customer's automated tooling can parse the fields without manual editing. Document the cases where a human-readable notice is the only sensible option.
Approval path for disclosure and delay
Annex I Part II point (4) allows a manufacturer to delay public disclosure in duly justified cases, where it judges that publication risks outweigh its benefits. Define who may approve a delay, who signs off the wording of a public advisory, how legal and communications teams are involved, and how each decision is recorded. Check it by running a tabletop exercise that reaches a decision within a defined window and produces a written justification. Without a named approver, a delay decision is often made informally and is hard to defend later.
Customer communication channel
Choose the channels that will carry a notice: a security mailing list, a customer portal, a status page or direct account contact for business users. Confirm that each channel can send to the register, that sending rights and credentials are held by more than one person, and that messages can be sent outside business hours. Check the channels by sending a test advisory through each one and confirming delivery and the timestamp. Keep one authoritative location where every advisory is published so that users can find it later.
PSIRT or coordinated disclosure process
A product security incident response team, or PSIRT, owns intake of vulnerability reports, triage, fix development and publication of advisories. Document how reports arrive, how severity is assessed, which advisory fields are filled in (description, affected products, impact, severity and remediation) and how security updates are released free of charge. Check the process by walking one hypothetical report (illustrative) from intake to advisory and confirming each step has a named owner and a recorded output. Make sure the process also covers the cases where a fix is not yet available, so users still receive workaround guidance.
Who owns the notice, who prepares it and who judges it
The manufacturer remains legally responsible for informing users under Article 14(8) and for public disclosure under Annex I Part II point (4). Decisions about whether an incident affects users, which mitigations to recommend and when to publish sit with the organization's leadership and its product security team. The organization also owns the wording of every notice, its tone, and the relationship with business customers who may have contractual rights to earlier or more detailed information.
- Decision authority: Name who may decide to notify affected users, delay publication under point (4), or stop a notice, and record the basis for each decision.
- Message ownership: Approve advisory text, severity wording and remediation steps before release, including any machine-readable format used.
- User relationships: Maintain the list of affected users and business customers, and decide how far the notice reaches under the duty to inform.
- Accountability: Hold the penalties exposure under Article 64, which is set by the manufacturer's own conduct rather than by any vendor.
- Legal review: Involve counsel on contract terms, cross-border users and any delay justification.
Check that your product security policy assigns each of these decisions to a named role before an incident occurs.
An implementation partner such as DeployOpen can prepare the systems and workflows the organization uses to notify users. It does not decide what to say, does not issue reports, and does not issue certificates. DeployOpen prepares systems, controls and evidence for compliance assessments, and independent auditors and certification bodies issue the reports or certificates. The partner's work is operational, and the organization stays the owner of every notice it sends.
- Contact data: Set up and maintain the user and customer contact records, with update procedures and access controls, so affected users can be reached quickly.
- Advisory workflows: Build templates, approval steps and distribution channels for advisories, including versioned records of what was sent and to whom.
- Update delivery: Configure the channels that deliver free security updates and advisory messages in self-hosted deployments within the client's own infrastructure.
- Evidence of execution: Capture logs, timestamps and sign-offs that show notices were issued, and prepare them for an independent assessor.
- Process testing: Run tabletop exercises or controlled tests of the notification process, and report gaps to the organization.
Ask any partner to confirm in writing which items are delivered and which remain with your own staff.
National market surveillance authorities enforce the regulation, and CSIRTs have a role in incident handling. Under Article 14(8), a CSIRT may inform users itself if the manufacturer does not do so in time. Independent bodies judge conformity: notified bodies assess products where the conformity route requires it, and an independent auditor or certification body issues any formal report. None of these parties writes the manufacturer's notice, and none of them accepts a notice on the manufacturer's behalf without its own process.
- Market surveillance: National authorities, coordinated through the administrative cooperation group, check products and can act on the basis of user notices or complaints.
- CSIRT action: A designated CSIRT may notify users when the manufacturer does not do so in time, which is a reason to plan notices early.
- Notified bodies: These assess conformity where the route requires it and are listed in the Commission's NANDO system.
- Independent assessors: Auditors and certification bodies test the process and issue any reports, based on evidence the organization provides.
- Guidance: Commission guidance on the duty to inform and on public disclosure is non-binding but shows how authorities are likely to read the rules.
Confirm with your authority or notified body which body is competent for your product before you rely on its view.
Frequently asked questions about informing CRA users
Do we have to notify users of every vulnerability we find?
No. The duty in Article 14(8) to inform impacted users, and where appropriate all users, attaches to incidents and to the vulnerabilities you report under Article 14. It does not extend to every defect you find. Commission FAQ 4.3.1 also states that the regulation does not require a patch for every vulnerability found during the support period. Your response depends on risk. For some issues the right step is an immediate patch. For others it may be a workaround advisory, an updated manual or configuration guidance that disables an affected feature. Document the risk reasoning for each decision, because an assessor will ask why a vulnerability was handled the way it was. Ask your counsel or conformity assessment body to confirm how your risk assessment maps to these response options.
What changes when a security fix does not exist yet?
The duty to inform users still applies, but the content shifts from a patch to mitigations. Article 14(8) asks you to tell impacted users about the incident and about the mitigations they can deploy. If no security update exists, mitigations may include disabling a feature, restricting network exposure, changing a configuration or removing a vulnerable component. Commission guidance C(2026) 5252 (section 9.1) notes that the duty to inform may be limited to affected users while risks persist. Keep the notice factual: what happened, which versions or configurations are affected, what users should do now, and when you expect to update them. Public disclosure under Annex I Part II point (4) follows a security update, so a notice sent before a fix is not the same as the public advisory. Confirm the sequence with your CSIRT and legal team before you send anything.
Can security notices to users be machine-readable?
Yes, where appropriate. Article 14(8) allows the information to users to be provided in a structured, machine-readable format where appropriate. This matters most for product fleets, industrial equipment and business customers whose tooling can ingest advisories automatically. Machine-readable notices usually carry product identifiers, affected version ranges, severity, fix status and remediation steps. Choose a format your customers can parse, and keep it consistent with the human-readable advisory so the two never disagree. Check whether your advisory channel can publish structured data, and whether your version metadata and software bill of materials are accurate enough to identify affected units. Version your schema so downstream systems can detect changes.
How long does the user notification work take and what do we need from internal teams?
The duration depends on your product, the size of your user base and how mature your advisory process already is. The regulation does not give a single duration for drafting a user notice, so treat any timeline from a provider as an estimate tied to a written scope. Product security supplies the technical facts, engineering builds the fixes and mitigations, support or customer success handles distribution, legal reviews wording and disclosure timing, and communications manages the channels. Start by mapping who decides, who signs off and how notices reach each customer group. Ask any provider for a plan that lists roles, deliverables and the points where your sign-off is required. Confirm with your counsel which reporting deadlines apply to each step.
Can a partner run user notifications for us, and what stays ours?
DeployOpen can prepare the systems and evidence around this process under a written, fixed scope, but the obligations and decisions remain with your organization as manufacturer. Work we can cover includes preparing advisory templates and machine-readable outputs, setting up the publishing workflow, testing the mechanism, documenting how decisions were made and supporting your internal team during an incident. What stays with you includes deciding whether a vulnerability is notifiable, approving content, choosing channels, deciding on delayed publication and signing off on what goes to customers and authorities. Independent auditors and certification bodies assess conformity and issue any reports or certificates. DeployOpen does not issue those. Ask any partner to state in writing which steps they perform, which they support and which you retain.
Can we delay public disclosure of a fixed vulnerability?
Yes, but only in duly justified cases. Annex I Part II point (4) allows you to delay publication until users have had the possibility to apply the patch, where you consider that the security risks of publication outweigh its benefits. The delay needs a documented justification and should be limited to the period needed for users to patch. Keep a record of when the fix became available, who weighed the risks, the reasons for the decision and when publication happened. Coordinate with your CSIRT, because reporting obligations run alongside disclosure. Commission guidance distinguishes the Article 14(8) duty to inform users, which may be limited to affected users while risks persist, from the public disclosure duty that follows a security update. Treat delay as an exception that needs evidence, not as a routine choice.
What fines apply under Article 64 for failures under Articles 13 and 14?
Under Article 64, breaches of Annex I and of Articles 13 and 14 can draw administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other listed obligations carry maximums of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries up to EUR 5 million or 1%, again whichever is higher. These figures are maximums, not fixed penalties. National market surveillance authorities enforce the regulation, so confirm with counsel how each Member State where you sell applies these caps. The Article 14 reporting obligations apply from 11 September 2026 and to in-scope products whenever they were placed on the market, so your user notice process should be ready before an incident occurs.
Who adds fixed vulnerabilities to the European vulnerability database?
ENISA adds them, not the manufacturer. Under Article 17(5), once a fix or mitigation is available and with the manufacturer's agreement, ENISA adds publicly known vulnerabilities notified under Article 14(1) or Article 15(1) to the European vulnerability database. Your agreement therefore matters, and your advisory should be ready to match the database entry. Check each notified vulnerability's status, fix availability and the wording already published, and keep your advisories consistent with what you submitted through the reporting process. Confirm with ENISA how entries are created and updated, since the mechanics depend on how the platform operates.
How DeployOpen prepares the notice process
DeployOpen helps manufacturers prepare the systems, templates and records needed to inform users after a CRA vulnerability or incident. The organization keeps ownership of its notices, decisions and disclosure timing, while we build the supporting workflow inside your own infrastructure.
How we scope
- Engagements are fixed-scope, with the notice channels, user groups and products agreed in writing before work starts.
- We confirm which user populations need Article 14(8) notices and which need public Annex I Part II point (4) disclosure.
- The written scope names who approves notices, who publishes advisories and which platforms are in the workflow.
How we build
- We set up advisory templates covering incident description, affected product identification, impacts, severity and mitigation steps.
- We prepare a machine-readable advisory format where your product and user channels can support it, and confirm the format with you.
- We document the justification process for any delayed publication, so decisions are recorded with the reasoning behind them.
How we hand over
- You receive the templates, approval workflow, distribution runbook and disclosure log as documented deliverables.
- We walk your product, security and communications teams through how each notice is produced, reviewed and released.
- Your team keeps the records that show when users were informed and when security updates became available.
How we support
- Ongoing support, upgrades and continuous testing of the notice workflow are available as a retainer.
- We can review your templates and workflow again when products change, support periods end or CRA guidance is updated.
- Notices remain your legal communications. Independent auditors or authorities assess them, and DeployOpen does not issue certifications.
