Cyber Resilience Act Compliance

The Cyber Resilience Act (Regulation (EU) 2024/2847), also known as CRA, sets mandatory cybersecurity requirements for products with digital elements (hardware and software) made available on the EU market, covering their entire lifecycle, from design to maintenance.

The CRA obligations fall on the product manufacturer. Since your connected products rely on Servitly to process their data remotely, the security of Servitly contributes to the security of your products, and it is already part of the way we work.

Below you will find the CRA requirements, and for each of them, where the arrow "→" is present, you can see how Servitly complies or supports you in complying.

Some points are also included in the ISO 27001 standard, so you will find the related points that address the specific requirement. For more details, you can refer to the ISO 27001 Compliance article.
If needed, we can share more information with you in a dedicated audit session.

Timeline

Scope

The CRA applies to products with a data connection to a device or network, including their remote data processing solutions.
According to the Commission guidance published on July 27, 2026, a remote service is part of the product when all of the following conditions are met:

• the data processing takes place at a distance from the product (e.g., in the cloud);

• its absence would prevent the product from performing one of its functions;

• it is designed and developed by the manufacturer, or under its responsibility.

Depending on how your product relies on it, the DPS can therefore be considered a remote data processing solution of your product, or a third-party component to be assessed with due diligence.
This evaluation is up to the manufacturer and must be done for each product model.
Cloud services that are not part of a product are outside the CRA scope and may fall under the NIS 2 directive (see NIS 2 Compliance).

Even though the device hardware and firmware are the responsibility of the manufacturer, below you will find how each requirement is managed from a cloud perspective.

Essential Cybersecurity Requirements (Annex I, Part I)

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks.

On the basis of the cybersecurity risk assessment, they must ensure:

• No known exploitable vulnerabilities when made available on the market → Libraries and packages are constantly checked for new vulnerabilities (CVEs), and VA/PT tests are periodically performed on the deployed platform.
  For more details, see Secure Development Practices and Continuous Improvement.

• Secure-by-default configuration, with the possibility to reset the product to its original state → Each environment passes a hardening procedure before deployment (e.g., default credentials removed, unnecessary services and ports disabled). Protective settings are active by default (e.g., login challenge after failed attempts, deactivation of inactive accounts) and can be further strengthened (e.g., password complexity, session duration, Two-Factor Authentication).
  Resetting the device to its original state is up to the manufacturer.
  For more details, see Account and Identity Security.

• Vulnerabilities addressed through security updates, automatic where applicable → Servitly is delivered as a cloud service, so security fixes are deployed centrally, without any action by users.
  For devices, the DPS lets you distribute firmware updates remotely, also marking them as mandatory → Firmware, Firmware Management.
  Automatic installation and postponement on the device are up to the manufacturer.

• Protection from unauthorized access, and reporting of possible unauthorized access → Access is controlled through authentication (also via OpenID Connect and Two-Factor Authentication), role-based permissions, and per-product credentials with ACLs on the IoT Connectors. Login attempts and user activities are logged and made available through the Audit Event List widget.
  For more details, see Account and Identity Security and IoT Connectors Security.

• Confidentiality of stored, transmitted, or processed data → Data in transit is encrypted with TLS 1.2 or 1.3, passwords are stored with one-way hashing, and secrets are kept in encrypted vaults → ISO 27001 (A.8.24), REST API Security, Data Masking and Filtering.

• Integrity of data, commands, programs, and configuration → Communications are protected against tampering (TLS, mutual TLS between internal components), invalid messages are discarded, and broker ACLs let each product publish and subscribe only to its own topics.
  Access to remote control features is governed by User Permissions.
  For more details, see IoT Connectors Security.

• Data minimization → You decide which data is collected by defining the metrics of each Thing Definition.
  Metric values are anonymized and stored separately from product and user data, and data is kept according to the Data Retention policy → Data Isolation, GDPR Compliance.

• Availability of essential functions, also after an incident, including protection against denial-of-service attacks → WAF, DDoS protection, load balancing, automated failover, and multi-zone deployments, supported by periodically tested business continuity and disaster recovery plans → Availability, Architectural Security, ISO 27001 (A.5.29, A.5.30).

• Minimal negative impact on other devices or networks → The Publishing Rate Limit and the Requests Rate Limits prevent a single product or client from degrading the service.

• Limited attack surface, including external interfaces → Only public-facing components (Web Frontend and API Gateway) are exposed in a DMZ, while backend services and databases reside in private subnets with no direct internet access. Unnecessary services and ports are disabled → Architectural Security, Secure Development Practices.

• Reduced impact of incidents through exploitation mitigation mechanisms → Defense-in-depth layered design, least-privilege microservices, zero-trust principles with short-lived tokens, and strict tenant and row-level isolation → Architectural Security, Data Isolation.

• Recording and monitoring of relevant internal activity → User activities, login attempts, and update operations are logged and made available through the Audit Event List widget, and the platform is continuously monitored → Monitoring and Logging, ISO 27001 (A.8.15, A.8.16).

• Secure removal of all data and settings, and secure data transfer → Users can exercise their rights, including data deletion, and data can be shared with users and third parties through secure channels → Rights for Individuals, DPS Compliance to the Data Act.

Vulnerability Handling Requirements (Annex I, Part II)

• Identify and document vulnerabilities and components, including a Software Bill of Materials (SBOM) → All third-party libraries and packages are inventoried and monitored for new vulnerabilities (CVEs) → ISO 27001 (A.5.9, A.8.8).

• Remediate vulnerabilities without delay, including by providing security updates → A risk assessment is performed on each discovered issue, which is then fixed according to the assigned priority and the SLA (Service Level Agreement).
  Where needed, the issue is temporarily mitigated (e.g., by disabling the affected service) until the patch is released → Secure Development Practices.

• Effective and regular security tests and reviews → Static code analysis, mandatory peer reviews, security checks in CI/CD pipelines, and periodic VA/PT tests carried out both in-house and by third-party companies → Secure Development Practices, ISO 27001 (A.8.29).

• Disclose information about fixed vulnerabilities → As stated in the Servitly Security Plan, discovered vulnerabilities are notified to customers and partners according to the severity and impact of the issue.
  Platform changes are published in the Release Notes.
  For device firmware, disclosure is up to the manufacturer; release notes can be attached to each firmware version → Firmware.

• Coordinated vulnerability disclosure policy and contact address for reporting vulnerabilities → Security Plan (internal document)

• Secure and timely distribution of updates → Platform updates are released through CI/CD pipelines with integrated security checks, and cloud resources are managed through Infrastructure as Code to ensure consistent configurations → Architectural Security.
  Firmware packages can be distributed to devices over HTTPS → Firmware.

• Security updates disseminated without delay, free of charge, and with advisory messages → Security fixes to the platform are included in the subscription at no additional cost.

Manufacturer Obligations (Article 13)

• Perform, document, and keep updated a cybersecurity risk assessment → Up to the manufacturer for the product. For the cloud, risks are assessed and treated as described in ISO 27001 (6, 8).

• Exercise due diligence when integrating third-party components → This article, the Security Framework, and the ISO 27001 Compliance article describe how Servitly is secured. Internal documents (e.g., Security Plan, Business Continuity Plan) can be reviewed in a dedicated audit session.

• Handle vulnerabilities for a support period of at least five years, unless the product is expected to be used for less time → The Servitly platform is continuously maintained, and security fixes are provided for the whole duration of the subscription, according to the SLA (Service Level Agreement).

• Report vulnerabilities found in integrated components to their maintainer → You can report any vulnerability affecting Servitly to the contact address above.

• Draw up the technical documentation, perform the conformity assessment, and affix the CE marking → Up to the manufacturer. The Servitly documentation can be the basis for describing the product's cloud component.

• Provide users with the required information and instructions (Annex II) → Up to the manufacturer. The DPS can make product Documentation and legal documents available to your users.

Reporting Obligations (Article 14)

Since September 11, 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of their products through the ENISA Single Reporting Platform, which forwards them to the competent CSIRT and to ENISA:

• Early warning: within 24 hours of becoming aware.

• Notification: within 72 hours of becoming aware.

• Final report: within 14 days after a corrective measure is available (vulnerabilities), or within one month after the notification (incidents).

Manufacturers must also inform the impacted users about the issue and, where necessary, about the corrective measures to apply.

Reporting to the authorities is up to the manufacturer. Servitly supports you in meeting the required timeframes:

• Actively exploited vulnerability affecting Servitly → We communicate it directly to the involved customers, trying to respect the required timeframes according to the impact, and we mitigate or fix it as described above.

• Severe incident affecting Servitly → We communicate it directly to the involved customers, trying to respect the required timeframes according to the impact.
  Any incident is documented (history, causes, logs, actions, lessons learnt) in an internal repository → ISO 27001 (A.5.24, A.5.26).