How to: Set up a vulnerability reporting procedure

Set up a procedure for your delivered Access application to record a vulnerability or security incident, report it on time, fix it, and close it, as Article 14 of Regulation (EU) 2024/2847 requires.

Since September 11, 2026, a manufacturer must send an early warning about an actively exploited vulnerability or a severe incident within 24 hours and a notification within 72 hours. The deadlines run through weekends. If you wait for the first case to decide who reports and how, you'll miss them. Background: Publisher obligations under the Cyber Resilience Act.

• Before your first delivery, decide on roles, a point of contact, access to the reporting platform, and where case files are kept.
• Every case goes through nine steps: intake, assessment, early warning, notification, user information, fix, security advisory, final report, and closure.
• Use the templates below for the early warning, the notification, the final report, and the user information.
• Deliver the fix as a new version; the starter installs it the next time each user starts the application.

graph TD
  E[Intake] --> T[Record and assess]
  T -->|not exploited| K[Fix and deliver]
  T -->|actively exploited or severe incident| F[Early warning, within 24 h]
  F --> M[Notification, within 72 h]
  M --> N[Inform users]
  M --> K
  K --> V[Publish a security advisory]
  K -->|reportable| A[Final report]
  V --> Z[Close the case]
  A --> Z

Rehearse the procedure once with a made-up case before your first delivery.

1. Intake. Open a case file right away and note the time. Notify the case owner and the reporter. Never store the content of a report in a publicly readable system: no public repositories, wikis, or work items, and no commit messages.
2. Assess within 4 hours of intake. Determine which versions and member states are affected, how severe the vulnerability is (for example, by CVSS), and whether there's reliable evidence of exploitation by a malicious actor or a severe incident (Article 14(5)). If the cause is in a component, such as a WKL component, also report the vulnerability to that component's manufacturer. Once you classify the case as reportable, the clock starts from the moment you became aware. When in doubt, report.
3. Early warning within 24 hours of becoming aware. Send the early warning through the platform. Say so when something isn't known yet.
4. Notification within 72 hours of becoming aware. Send the notification. If the CSIRT asks for an intermediate report, use the same template.
5. Inform users. Tell affected users which measures they can take, using the user information. If early publication would help attackers, agree on the timing with the CSIRT.

6. Fix and deliver. Build the fix as a separate version, ideally without new features, and deliver it free of charge:

   wkl-office deliver Customers.acproj --version 1.4.1

   If you use a delivery key, sign the version afterward with the starter's /publish /key. Keep every security update available for at least ten years or for the rest of the support period, whichever is longer.

7. Publish a security advisory. Once the fix is available, describe the vulnerability, the affected and fixed versions, the impact, the severity, and the steps to fix it (Annex I, Part II, point 4).
8. Final report. Send the final report: for a vulnerability, no later than 14 days after a corrective or mitigating measure is available; for an incident, within one month of the notification.
9. Close the case. Close the case file and note what you'll change in the procedure.

Manufacturer:        <name, address>
Contact:             <reporter, phone, email>
Type:                actively exploited vulnerability | severe incident
Product:             <application>, versions <...>
Aware since:         <date, time, time zone>
Member states:       <states where, to your knowledge, the application is available>
Incidents only:      suspected unlawful or malicious act: yes | no | not yet known
Summary:             <one to three sentences, as far as known>
Sensitivity:         <how sensitive the information is>

Reference:           early warning of <date>, platform ID <...>
Product:             <application>, affected versions <...>, unaffected versions <...>
Type:                <vulnerability or incident, severity; for an incident, an initial assessment>
Exploitation:        <what was observed, as far as known>
Measures taken:      <fix in progress, interim mitigation, customers informed>
Measures for users:  <what users can do now>
Sensitivity:         <how sensitive the information is>

Reference:           notification of <date>, platform ID <...>
Description:         <vulnerability or incident, severity, impact>
Cause:               <for an incident: type of threat or root cause>
Actor:               <for a vulnerability: information on a malicious actor, if available>
Fix:                 <version, date available, how to get it>
Further measures:    <measures taken and ongoing>

Subject: Security advisory <ID> - <application> <versions>
 
What's affected:     <application and versions>
What's the risk:     <plain description, severity>
What to do now:      <steps>
Fix:                 <version and how to get it, or expected date>
Contact:             <your point of contact>

• The templates list what a notification should contain. If the platform's fields differ, follow the platform.
• Vulnerabilities that aren't exploited don't have to be reported. You still fix them and publish a security advisory once the fix is available.
• This page is a template for your own procedure, not legal advice. The obligations are yours as the manufacturer of your application.

• Publisher obligations under the Cyber Resilience Act – deadlines, obligations, and what the SDK and the starter contribute
• Deliver an application from the SDK – deliver a fix as a new version