The EU Cyber Resilience Act (CRA) is now entering into force, and companies are realizing that their digital products fall directly under this new regulation. Penalties for non-compliance are severe, and product owners bear sole responsibility for their solutions. Starting in September 2026, Phase 1 of the CRA takes effect: manufacturers must have an active vulnerability monitoring system in place and report actively exploited or severe vulnerabilities to government regulators within 24 hours.
Any company that produces a Product with Digital Elements (PDE) and distributes it in the EU must comply with the CRA. A PDE is officially defined as: "A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately."
A product falls under the scope of the CRA as a PDE if it is made available on the EU market and its intended or reasonably foreseeable use involves a direct or indirect logical or physical data connection to another device or network.
Websites and PWAs (Progressive Web Apps) do not fall under the scope of the CRA. While a PWA can be pinned to a mobile phone's home screen and visually behave exactly like a native mobile application, it is technically still a website.
Our client is a heavy machinery manufacturer in Finland with a companion mobile app for their vehicles. It is a native mobile application and it must comply with CRA. The CRA compliance process is divided into two major phases:
Based on the Cyber Resilience Act (CRA) requirements for Phase 1, here is exactly what the law mandates and the corresponding project milestones that cover each requirement:
Mandatory Incident Reporting (Article 14 & Article 16): The law dictates that manufacturers must report actively exploited vulnerabilities or severe security incidents to the state regulator (e.g., Traficom in Finland) and the ENISA Single Reporting Platform within 24 hours (Early Warning Report), followed by a detailed notification within 72 hours.
Implementation: Incident Reporting has a very tight timeline: 24h after receiving information about possible incidents to provide the Early Warning Report to the state regulator. This 24-hour clock includes weekends and holidays. This strictly requires an active Incident Reaction Plan with clearly defined roles and pre-filled reporting templates. Also the incident notification system must exist.
Continuous Component Tracking and Threat Monitoring: To meet the 24-hour reporting deadline, manufacturers must maintain an up-to-date registry of all product components and continuously monitor them against global vulnerability databases.
Implementation: It is a core of the incident notification system for Incident Reporting. An Application Security Posture Management (ASPM) platform automatically gets the Software Bill of Materials (SBOM) from each release build and continuously cross-references it against global vulnerability databases to trigger immediate alerts when threats are detected. Implementation requires creating the SBOM in CI/CD pipeline for each release.
To make SBOM reliable and legally valid, we need reproducible builds and strict version lock for all dependencies (like package-lock.json and Podfile.lock). Consequently, building mobile releases on a developer's local machine is no longer acceptable. Local environments always have dirty cache and inconsistent tool versions, which breaks reproducible builds.
The solution is to use isolated CI/CD environments. For Android applications, the standard solution is building inside an isolated Docker container or clean Linux VM with fixed build-tools. For iOS applications, where compilation requires macOS and Xcode, we must use dedicated cloud macOS instances to guarantee clean, reproducible builds and generate exact SBOM artifacts for each release.
Vulnerability Handling and Risk Mitigation (Annex I, Part II): Manufacturers are legally required to "address and remediate vulnerabilities without delay" and "ensure effective mitigation of risks for users" before they are exploited.
Implementation: Vulnerability Handling and Risk Mitigation requirements are best met in a mobile app by implementing an emergency “kill-switch”. If the app has an actively exploited vulnerability, we can block users from using it and notify them about the security issue. On every launch, the mobile app checks a remote endpoint before starting any user activity. If the endpoint marks the current app version as outdated or compromised, the app shows a message to the user and stops working.
This endpoint must have high availability and load very fast. The best approach is to use a static JSON configuration file with version requirements hosted on a public server and cached by a CDN. In addition, the Incident Reaction Plan must clearly define the responsible person who updates this file when a critical vulnerability is discovered.
Public Vulnerability Reporting Mechanism (Annex I, Part II): The CRA mandates that a product must provide a public channel where security researchers and users can report security issues, and this channel must allow for anonymous reporting.
Implementation: Anyone, including anonymous users or external security researchers, must be able to report a discovered vulnerability without restriction. Once submitted, this report must trigger an immediate notification directly to the designated responsible person at the company in accordance with the Incident Reaction Plan to start the mandatory 24-hour response clock.
The CRA incident reporting mandates a strict timeline: an Early Warning Report must be submitted within 24 hours, followed by a detailed incident notification within 72 hours. To remain legally compliant and avoid heavy fines, the Product with Digital Elements (PDE) manufacturer must investigate alerts and take action immediately.
In practice, industrial manufacturing companies rarely have dedicated in-house security teams available to monitor vulnerability feeds 365 days a year.
To bridge this gap, we provide an ongoing Tier 1 CRA Monitoring SLA as a Technology Partner:
To be continued in Phase 2…