Regulations

CRA, UKSC and NIS2 — three regimes, three different sets of obligations

How the CRA differs from NIS2 and Poland's amended National Cybersecurity System Act, who receives reports in Poland and why the deadlines don't line up.

Michał Jaśniewski October 24, 2026 8 min read

The CRA regulates the product; NIS2 — and the amended Polish National Cybersecurity System Act (ustawa o krajowym systemie cyberbezpieczeństwa, UKSC) that transposes it — regulates the organization. That distinction resolves almost every practical question: a software house may not be an essential or important entity under the UKSC and still be a manufacturer under the CRA — and vice versa. Reports go to different recipients, through different channels and for different reasons. Under the CRA, they go through the EU single reporting platform (SRP) to the CSIRT designated as coordinator (in Poland, the CVD route at CERT Polska / CSIRT NASK) and simultaneously to ENISA. Under the UKSC, they go through Poland’s S46 system to the sector CSIRT and from there to the national CSIRT.

What is regulated: the product versus the entity

The CRA is product legislation, built on the same logic as CE marking for machinery or electrical equipment. The obligation falls on the economic operator placing the product on the market, and the ultimate sanction is removing the product from the market (Articles 54–58).

NIS2 and the UKSC are entity-based legislation. They apply to an organization that falls within a covered sector and size threshold, and they govern risk management, business continuity and incident reporting in its own operations.

NASK’s analysis points directly to the gap the CRA closes: earlier legislation, including NIS2 and the Cybersecurity Act, did not impose mandatory security requirements directly on the products themselves.

For a software vendor, the consequence is twofold. As an organization, it may fall under the UKSC. As a manufacturer, it falls under the CRA. And as a supplier to an essential entity, it faces a third source of pressure — its customer’s supply chain requirements, imposed by contract rather than by statute.

The legal position in Poland

The CRA applies directly, with no implementing act needed. Article 14 (reporting) applies from 11 September 2026, the provisions on notification of conformity assessment bodies from 11 June 2026, and the remaining obligations — including technical documentation and CE marking — from 11 December 2027.

The amended UKSC — the Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts, published on 2 March 2026 (Journal of Laws 2026, item 252), entered into force on 3 April 2026.

NIS2 is a directive, so it does not apply directly — it binds through national law, which in Poland means the UKSC.

The UKSC implementation schedule spreads the obligations over time: applications for entry in the register of essential and important entities by 3 October 2026; an information security management system in place and a connection to the S46 system within 12 months of being classified as an essential or important entity; the first audit of essential entities within 24 months; and financial penalties, as a rule, only two years after the provisions entered into force.

A stretched-out penalty calendar does not reduce the number of obligations. It only reduces the financial risk of the first phase.

Who receives the report in Poland

This is the question that most often leads to operational mistakes, because the answer is different for each regime.

CRA. The manufacturer reports once, through the single reporting platform operated by ENISA under Article 16. The first recipient is the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment (Article 14(7)); ENISA receives the notification simultaneously. On the list of CSIRTs designated as coordinators maintained by ENISA (updated 10 September 2026), the contact point for Poland is the coordinated vulnerability disclosure route at CERT Polska / CSIRT NASK. The CSIRT that received the notification passes it on to the coordinator CSIRTs of the Member States where the product is available, and national CSIRTs then share the necessary information with their market surveillance authorities.

UKSC. A report of a serious incident (incydent poważny, the Polish counterpart of a NIS2 significant incident) goes first to the sector CSIRT, which forwards it to the competent national CSIRT — NASK, GOV or MON — without delay and no later than within 8 hours. All communication is meant to run through the central S46 system, and failing to use it is subject to penalties. Sector CSIRTs are to be set up within 18 months, with the option of entrusting their tasks to a national CSIRT by agreement.

The point of overlap: CSIRT NASK is also the national coordinator for coordinated vulnerability disclosure. The same institution appears in both regimes, but in different roles and through different channels — and it is the channel, not the institution, that determines whether the report counts as filed.

The deadlines look alike but are counted differently

Three stages in both regimes is a similarity of structure, not of substance.

CRA (Article 14)NIS2 / UKSC (Article 23 NIS2)
What is reportedan actively exploited vulnerability in the product; a severe incident having an impact on the security of the producta significant incident in the entity’s operations
Early warning24 h after becoming aware24 h after becoming aware
Notification72 h72 h
Final reportvulnerability: 14 days after a corrective measure is available; incident: 1 month after the notification1 month after the notification
Recipientcoordinator CSIRT + ENISA via the SRPsector CSIRT → national CSIRT via S46

Two differences matter operationally.

First, under the CRA the 14-day deadline for a vulnerability is tied to the availability of a fix, not to the date of the notification. A case can stay open for months, and the clock for the last stage only starts on the day the update is released.

Second, the thresholds differ. A “severe incident” under the CRA is defined in Article 14(5) by reference to the product’s ability to protect data and functions, and to the introduction of malicious code. A “significant incident” under NIS2 (Article 23(3)) is defined by severe operational disruption of services, financial loss for the entity, or considerable damage to other persons. The same event can meet one threshold and miss the other.

One event, two reports

A scenario companies should work through before it happens, not after: a Polish software manufacturer that is also classified as an important entity learns of an actively exploited vulnerability in its own product, which has also led to a compromise of its production environment.

Under the CRA: an early warning notification within 24 hours through the SRP to CSIRT NASK as coordinator and to ENISA, a notification within 72 hours, a final report within 14 days of releasing the fix — plus the duty to inform users under Article 14(8).

Under the UKSC: a serious incident report through S46 to the sector CSIRT, within the deadlines set by the Act.

That is two paths, two sets of fields, two time records. A single reporting process that handles both regimes is achievable, but it has to be designed — it does not emerge by analogy. (The CRA side step by step: CRA reporting deadlines.)

The supply chain: a third, contractual regime

For a software vendor working with regulated sectors, the biggest day-to-day cost comes neither from the CRA nor from the UKSC, but from customer requirements.

Essential and important entities implement, as part of their information security management system, measures that cover supply chain security. They pass them on to suppliers by contract — security questionnaires, SLA clauses on patching, the right to audit (more in NIS2 and supply chain security).

The amended UKSC adds a high-risk vendor mechanism on top: the minister responsible for digital affairs may, after obtaining the opinion of the Cybersecurity College (Kolegium ds. Cyberbezpieczeństwa), issue a decision phasing out specified hardware or software, with a withdrawal period of 4 years (telecommunications, or the list of critical function categories) or 7 years (other entities).

Here the CRA works in the opposite direction to what you might expect: the Annex VII technical documentation, the SBOM and the CVD policy are the very artifacts a vendor assessment questionnaire asks for. One set of evidence serves both product compliance and sales into regulated sectors.

Precedence and supervision

The CRA does not replace sector-specific rules. Where sectoral legislation provides an equivalent or higher level of protection, it takes precedence — as with medical devices, aviation and motor vehicles, among others (Article 2 excludes these categories from the scope).

The CRA is supervised by market surveillance authorities designated by the Member States, cooperating with national cybersecurity certification authorities, CSIRTs, ENISA and data protection authorities; each Member State also designates a single liaison office. NASK’s analysis does not state which body acts as the market surveillance authority for the CRA in Poland — check the current announcements from the Ministry of Digital Affairs.

Supervision under the UKSC remains with the competent sectoral authorities and with the minister responsible for digital affairs, who maintains the register of entities.

Sources

For information only, not legal advice. This article covers the technical and process layer of the obligations under Regulation (EU) 2024/2847, Directive (EU) 2022/2555 and the Polish National Cybersecurity System Act; full compliance also requires organizational and legal work on your side and does not replace legal advice or a formal conformity assessment. Current as of October 2026.

CRAUKSCNIS2Regulations