Cyber Resilience Act for Cyprus software vendors: 2026–27 roadmap

Decide whether the offering is a product with digital elements

The CRA concerns products with digital elements made available on the EU market where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Software can be the product; a physical gadget is not required. Start with the precise item supplied under the company's name: a downloadable application, firmware, plug-in, networked device or integrated combination. Note who places it on the market, who controls the design and who provides updates. A company incorporated in Cyprus is not exempt when the product is offered across the EU.

The scope decision must distinguish a product from a service. The regulation can include a remote data processing solution designed and developed by or for the product manufacturer when the product cannot perform a function without it. An app whose core feature relies on the manufacturer's API may therefore require the backend element to be considered in the product-security assessment. By contrast, the CRA recital explains that an unrelated website or cloud service outside the manufacturer's responsibility is not automatically part of that product. Ordinary SaaS is not simply rebranded as a CRA product because it runs on the internet; assess its facts and other regimes separately.

Record exclusions and borderline cases instead of relying on a sales label. Some product categories are governed by specific EU legislation and have CRA exclusions or tailored interaction rules. Free and open-source code supplied outside a commercial activity has a different position from a company placing a commercial product on the market; an open-source software steward has a distinct set of obligations. Identify each product line, release channel, commercial model, intended users and remote dependencies. Where the answer is uncertain, preserve the reasoning and review the Commission's latest implementation guidance before deciding that the CRA is irrelevant.

For a separate platform-operator issue, see the DSA notice-and-action guide.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: 2026 guidance on applying the Cyber Resilience Act

Assign manufacturer, importer and distributor roles per product

The CRA places the main design, conformity and vulnerability-handling duties on the manufacturer: the person or entity that develops or has a product developed and markets it under its name or trademark. A Cyprus firm may be a manufacturer even if developers work abroad or the code includes third-party components. A reseller of a product made outside the Union may instead be an importer or distributor, with different verification and cooperation duties. White-labelling can change the role analysis. Put the actual trademark, contractual supply chain and release control on the decision file.

For each line, identify who owns the security architecture, approves dependencies, signs the EU declaration of conformity, maintains technical documentation and receives vulnerability reports. If the firm integrates open-source packages, it still needs due diligence and a process to address vulnerabilities in components. A purchase contract saying the upstream coder is responsible does not automatically shift statutory manufacturer duties away from the entity placing the finished product on the market under its brand. Conversely, a marketplace merely facilitating another seller's product is not necessarily the manufacturer; its platform duties require a separate analysis.

A product can also change over time. A substantial modification after the main application date may bring an older placed product into the full framework. Record release history, major feature changes, security-relevant integrations and the entity that made each change. Keep the role map current when the product is acquired, sold or moved into a new group company. This matters for incident reporting because the team needs to know which legal entity must notify and who has enough technical knowledge to make a timely assessment.

For marketplace-specific trader onboarding, see the DSA trader-traceability guide.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: 2026 guidance on applying the Cyber Resilience Act

Treat the 2026 reporting duty as live, ahead of 2027 conformity

The CRA entered into force in December 2024. Its Article 14 reporting obligations for manufacturers apply from 11 September 2026; the main product requirements generally apply from 11 December 2027. The Commission states that reporting covers products with digital elements already made available on the EU market, including products placed before the 2027 date. Do not wait for a future CE-marking project to establish the reporting route. Conversely, do not claim that a pre-2027 product has already undergone the CRA's full conformity procedure simply because its security team is handling incidents.

An actively exploited vulnerability is not the same as every theoretical weakness discovered in a code scan. A severe incident is not every minor support ticket. Build triage around the Act's definitions and the factual effect on product security. Article 14 requires an early warning within 24 hours after awareness and a notification within 72 hours, with later final-report deadlines that differ for a vulnerability and a severe incident. Use the statutory triggers and current Commission guidance; a general customer-response SLA or an internal monthly vulnerability meeting is not a substitute for the reporting clock.

The reporting duty for open-source software stewards has a later start under Article 24(3), from 11 December 2027. Do not apply the manufacturer's current reporting timeline to an entity solely because it publishes code in a repository; first determine its legal role and whether a product is commercially made available. Maintain a dated matrix with each product, role, market availability, applicable start date and responsible incident contact. The matrix should be reviewed after a new release or business-model change, rather than kept as a one-off launch memo.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act reporting obligations; ENISA: CRA Single Reporting Platform; European Commission: Cyber Resilience Act legislative summary

Build the ENISA reporting workflow before an emergency

ENISA's Single Reporting Platform has been operational since 11 September 2026 for CRA notifications. The Commission says the manufacturer reports once through the platform to its designated CSIRT coordinator and ENISA; the receiving CSIRT handles onward dissemination under the regulation's rules. For a Cyprus manufacturer, check the current coordinator information and platform instructions rather than sending an ordinary email to an old incident address. Register an assigned representative and backup, test account access and keep the authentication method available to the incident team outside normal office hours.

The initial notice can be based on information available early; the team should not delay it until root-cause analysis is complete. Capture awareness time, product and affected versions, evidence of active exploitation or severity, known impact, measures taken and remaining uncertainty. The Commission describes an early warning within 24 hours and fuller notification within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective measure becomes available; for a severe incident, within one month of the 72-hour notification. Record the chronology and who approved each submission.

Make parallel communication decisions deliberately. The CRA may require information to affected users about an actively exploited vulnerability or severe incident, while GDPR can impose a separate personal-data breach analysis and other sector rules may have their own reporting trigger. Use one incident record with separate legal clocks, recipients and content owners; do not assume a CRA submission automatically satisfies a GDPR notification or a client contract. ENISA publishes current platform FAQs and manuals; review them after material platform changes. A rehearsed incident run should include a weekend scenario, a cloud-component vulnerability and a failed representative login.

For the distinct personal-data incident test, read the Cyprus GDPR breach-response guide.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act reporting obligations; ENISA: CRA Single Reporting Platform; ENISA: assigned representative notification guidance; Regulation (EU) 2016/679, GDPR, breach notification Articles 33 and 34

Translate Annex I into a product security backlog

Annex I has two connected parts: security properties of the product and vulnerability handling during its support period. Article 13 requires a cybersecurity risk assessment to inform the design, development, production and maintenance decisions. Start with intended use, reasonably foreseeable misuse, threat surfaces and consequences of compromise. Then turn the assessment into release criteria: appropriate secure defaults, access control, attack-surface reduction, protection of confidentiality and integrity, availability and security updates. A generic penetration-test certificate cannot explain how all versions and components meet the applicable requirements.

Build a reliable dependency and vulnerability process. Know which third-party and open-source components are in each shipped version, how fixes are assessed and who can issue a security update. Define a vulnerability intake route, triage ownership, coordinated disclosure procedure and evidence of resolution. The CRA requires due diligence when integrating components and effective handling of vulnerabilities; the technical documentation needs to make the process inspectable. A machine-readable component inventory may help the team operationally, but do not imply that one file format alone proves compliance with every Annex I requirement.

Use risk-based implementation, not a blanket claim that every feature requires identical controls. A low-impact local utility and a remote administration product may need very different authentication, logging, isolation and testing. The assessment should explain those differences and be revised when the threat landscape or product architecture changes. Include the remote service that is necessary for the product's function in the architecture review. Test update delivery and rollback, because an untested patch path can turn a good vulnerability policy into an outage. Preserve release evidence so the conformity file matches the code actually distributed.

Where the product collects user data, address the separate privacy-by-design layer in the Cyprus GDPR compliance guide.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: 2026 guidance on applying the Cyber Resilience Act

Set a defensible support period and tell users how to stay secure

Under Article 13, the manufacturer determines a support period based on the time the product is expected to be used, taking account of reasonable user expectations and other factors in the regulation. The period is normally at least five years; it may correspond to a shorter expected lifetime where the product is expected to be used for less than five years. Do not turn the exception into a default for annual subscriptions without analysing whether the product or version genuinely ceases to be used. A long-lived network appliance or desktop tool may require a period longer than five years. Document the factors and decision for each product family.

Plan resources for the full support commitment: security monitoring, component updates, signing keys, deployment infrastructure, user communication and staff continuity. A product sold cheaply today can carry a later maintenance burden. Provide the support end date, including month and year, in a clear and understandable way at the time of purchase as the Commission explains. Avoid a hidden date that conflicts with the commercial promise. If a buyer relies on the product for a regulated service, disclose lifecycle and update constraints early enough for that buyer to assess its own risk.

User instructions under Annex II should enable secure installation, operation and use. Include the security update route, reporting contact, supported versions and material dependencies in the relevant product documentation. Test whether a real user can find a patch and understand when a feature or version becomes unsupported. Where an update is security-critical, design communication that identifies affected versions without needlessly exposing exploit details. Product guidance should match release behaviour: an auto-update claim is misleading if some deployed customers remain on a vulnerable build without any alert.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: 2026 guidance on applying the Cyber Resilience Act

Prepare the 2027 conformity route without assuming self-assessment

For a product to which the main requirements apply, the manufacturer must assess conformity, compile technical documentation, draw up the EU declaration of conformity and apply CE marking before placing it on the market. The technical file should connect the risk assessment, security requirements, design decisions, tests, vulnerabilities and instructions to the actual product version. A marketing page saying 'CRA compliant' is not a conformity assessment. Make the product team responsible for evidence collection during development; reconstructing months of design choices immediately before the 2027 deadline is expensive and unreliable.

The applicable assessment route depends on product category and available harmonised standards or certification schemes. The Commission's summary says ordinary products can generally use internal control, while products with the core functionality of an important or critical category in Annexes III or IV may require a different procedure. Do not assume that any cybersecurity certificate, SOC report or supplier assurance is the required route. Check the current delegated acts describing product categories and the standards actually cited in the EU framework. Record why the product falls in its category and who signed the final declaration.

Handle older products precisely. The Commission says products placed on the market before 11 December 2027 face the main CRA framework if they undergo a substantial modification from that date, while reporting duties already cover products made available on the market. A new major version may need fresh scope and conformity analysis; a routine patch should not automatically be labelled substantial without evaluating the statutory test. Maintain a release decision record that considers security impact, product identity and customer-facing functions. This avoids both unnecessary reclassification and the opposite risk of shipping a substantially changed product on an obsolete file.

For an adjacent product duty concerning accessibility, see the Cyprus e-commerce accessibility guide.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: 2026 guidance on applying the Cyber Resilience Act

Run three evidence-based launch tests

Test scope with two real offerings: a downloaded application that calls the company's own API and a separate cloud-only subscription. Write down why each does or does not meet the product and remote-processing definitions; identify the manufacturer and any importer or distributor. Then test a vulnerability affecting a dependency in a version sold last year. Can the team identify affected products, determine whether exploitation is active, start the Article 14 clock and reach the ENISA platform? The old sale date does not by itself remove a current reporting duty.

Test the security maintenance promise. Choose a product with a five-year or longer expected life and calculate what updates, support staff and key-management controls are needed throughout that period. Can a user see the support end date and obtain a security patch? Can the team trace the shipped component to its version and the fix? If the answer depends on a single developer's memory or a supplier that has no response obligation, improve the process before enlarging the market. Keep dated results and responsible owners rather than only a policy PDF.

Finally, test the 2027 conformity file against an actual release candidate: scope decision, risk assessment, Annex I control evidence, component review, user instructions, support-period decision, applicable assessment procedure and declaration owner. Resolve gaps by release, not by adding unsupported claims to the website. Recheck current Commission and ENISA materials at each milestone; the law's staged application dates, delegated acts and reporting-platform guidance make a static checklist fragile. A defensible record shows both what the company concluded and what the product actually does.

Basis and guidance: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV; European Commission: Cyber Resilience Act legislative summary; European Commission: Cyber Resilience Act reporting obligations; ENISA: CRA Single Reporting Platform

Primary sources and scope

Sources checked: October 7, 2026. This guide concerns the Republic of Cyprus. Examples are hypothetical, not client case studies. Check current official requirements before making a filing.

• Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 2, 3, 13, 14 and 71 and Annexes I–IV
• European Commission: Cyber Resilience Act legislative summary
• European Commission: Cyber Resilience Act reporting obligations
• European Commission: 2026 guidance on applying the Cyber Resilience Act
• ENISA: CRA Single Reporting Platform
• ENISA: assigned representative notification guidance
• Regulation (EU) 2016/679, GDPR, breach notification Articles 33 and 34

Practical guides for this topic

• Cyprus NIS2 scope: essential and important entity assessment

  Assess Cyprus NIS2 scope under Law 89(I)/2020 as amended in 2025: Annex sectors, size exceptions, essential versus important status, DSA notification and national reporting rules.