Publisher obligations under the Cyber Resilience Act

graph TD
  P[Publisher of the application] --> D[Delivery with the SDK]
  D --> M[app-manifest.json with SHA-256]
  D --> S[delivery.json signed with the delivery key]
  M --> B[The starter checks every copy]
  S --> B
  P --> R[Reporting procedure for vulnerabilities and incidents]
  R --> C[CSIRT and ENISA through the single reporting platform]
  R --> U[Information for users]

If you deliver an Access application built with the WKL Office SDK to customers, you're the manufacturer of that application under Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA). This page summarizes what the regulation requires of you and which parts the SDK and the starter support.

Key points

Reporting obligations already apply. Article 14 has applied since September 11, 2026; the other obligations apply from December 11, 2027 (Article 71(2)). Reporting applies from the moment you first make your application available on the EU market, including free deliveries in the course of your business.
Verifiable deliveries. Every delivered database is listed with its size and SHA-256 hash in app-manifest.json. The starter only places copies that match.
Signed deliveries. With a delivery key of your own, you sign the list of all files in a version. Starters that carry your public key install only what you signed.
A template for the reporting procedure. Set up a vulnerability reporting procedure walks through every step from the first report to the final report, with a template for each notification.

How the regulation and the tools fit together

Who the manufacturer is

The manufacturer is whoever develops a product with digital elements, or has it developed, and markets it under their own name or trademark. For an application built with the SDK, that's you, not the provider of the SDK. The SDK and the WKL components are components of your application. If you find a vulnerability in a component, report it to that component's manufacturer (Article 13(6)). The manufacturer of the SDK and the WKL components is EMSR DATA, D.O.O.; how to report a vulnerability in the SDK is described in SECURITY.md in the root folder of the SDK package.

What you must report

Event	Early warning	Notification	Final report
Actively exploited vulnerability	Within 24 hours of becoming aware	Within 72 hours of becoming aware	No later than 14 days after a corrective or mitigating measure is available
Severe incident affecting the security of the application	Within 24 hours of becoming aware	Within 72 hours of becoming aware	Within one month of the notification

A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission (Article 3(42)). You report through ENISA's single reporting platform (CRA Single Reporting Platform, CRA-SRP) to the coordinating CSIRT of the member state of your main establishment. ENISA receives the report at the same time, and the CSIRT forwards it to the CSIRTs of the member states where your application is available (Articles 14(7) and 16). You also inform affected users about the measures they can take (Article 14(8)).

In your member state

Coordinating CSIRT: the CSIRT that your member state has designated as coordinator for coordinated vulnerability disclosure. What counts is the member state where you mainly make the cybersecurity decisions for your application; you select the CSIRT on the platform when you report.
Reporting platform: registration and questions through ENISA's FAQ page, https://www.enisa.europa.eu/cra-srp (help desk cra-srp-helpdesk@enisa.europa.eu). Register before your first delivery, not during an incident.
National cybersecurity law: national laws that implement the NIS 2 Directive add reporting obligations for essential and important entities. They apply to your company only if it is such an entity, and to your customers if they are. They don't replace the CRA notification.

What your delivery must include

From December 11, 2027, every delivery must include, among other things, your manufacturer details, a single point of contact for vulnerabilities, the end date of the support period (at least five years, unless the application is expected to be in use for less time), and instructions for using the application safely (Article 13(8), (17), and (19), Annex II). You must also keep a software bill of materials (SBOM), a machine-readable list of the components contained in the application; it covers at least the top-level dependencies (Annex I, Part II, point 1). You must distribute updates through a mechanism that protects them (Annex I, Part II, point 7).

Before you make your application available from December 11, 2027, you assess its conformity. If it belongs to no category of important or critical products (Annexes III and IV, described in Implementing Regulation (EU) 2025/2392), the internal control procedure (module A, Annex VIII, Part I) is enough, without a notified body. You then draw up the EU declaration of conformity, include it, or a simplified declaration that gives the internet address of the full one, with every delivery, and affix the CE marking to the declaration or to the website accompanying your application. You keep the technical documentation and the declaration for at least ten years (Article 13(12), (13), and (20), Articles 28, 30, and 32).

The SDK shows what manufacturer details and a reporting route can look like: its package contains, in the root folder, MANUFACTURER.md (manufacturer details, type and end of security support) and SECURITY.md (reporting route and policy on coordinated vulnerability disclosure), each in English, German (.de.md), and Slovenian (.sl.md). Your application needs equivalent information with your company, your contacts, and your dates.

Where the SDK and the starter help

Obligation	Support	Limit
Distribute updates through a protected mechanism (Annex I, Part II, point 7)	`wkl-office deliver` writes `app-manifest.json` with the size and SHA-256 hash of the database; the starter checks every copy against it	Proves integrity, not origin
Prove where a delivery comes from	Signed deliveries: the starter's `/publish /key` writes `delivery.json` with the size and SHA-256 hash of every file and signs it with your delivery key (ECDSA P-256); starters with a `deliveryKey` install only signed versions	Programs run from `actions` aren't covered; the protection depends on users being unable to change the starter's project file (section “Signed deliveries” of the starter's project file)
Keep users from going back to a vulnerable version	From starter 2.2.4 a starter with `deliveryKey` installs a lower version than the user ever had only when the signed delivery withdraws the higher one; you go back on purpose with `/publish /key <name> /withdraw <version>` (Publish a signed delivery of the starter)	A user who never had the higher version installs the older delivery; `deliver` warns when the starter package is older than 2.2.4
Distribute security updates without delay (Annex I, Part II, point 8)	The starter installs a new version the next time each user starts the application	Putting the version on the share is up to you
Instructions for installing, updating, and removing (Annex II, point 8)	The starter's documentation covers installation, updates, and removal (`/uninstall`) for IT	Instructions for your application are yours to write
Software bill of materials (Annex I, Part II, point 1)	`wkl-office deliver` writes `sbom.cdx.json` (CycloneDX 1.6, data fields of BSI TR-03183-2): the application, every delivered file with SHA-512, the starter and the WKL libraries, and what the application needs on the computer	Manufacturer and licence come from your publisher profile and project file; components your application loads in other ways (a driver it installs itself, files it downloads) are not listed
Reporting procedure (Article 14)	A template with steps, deadlines, and notification texts	You decide on the people, platform access, and where case files are kept

Not supported today: support-period information. You provide it yourself.

How to use this page

This page summarizes the obligations you have as the manufacturer of your application and shows what the SDK and the starter contribute. The text of the regulation is binding. Whether your application is an important or critical product, and which conformity assessment it needs, you determine from Annexes III and IV, with your legal counsel if needed. This page is based on the regulation as published in the Official Journal of the European Union (OJ L, 20.11.2024, http://data.europa.eu/eli/reg/2024/2847/oj), on Implementing Regulation (EU) 2025/2392 (OJ L, 1.12.2025, http://data.europa.eu/eli/reg_impl/2025/2392/oj), and on ENISA's factsheet on the single reporting platform (September 2026).