On 18 March 2026, Maria Raphael participated in the panel “Blockchain & Cybersecurity – Preparing for CRA and NIS2” during the “Joining Forces for Blockchain Standardisation” event organised by INATBA in collaboration with the European Commission.

The discussion examined how blockchain ecosystems are preparing for Europe’s evolving cybersecurity framework, with particular focus on the Cyber Resilience Act and the NIS2 Directive.

The conversation reflected a broader shift taking place across the sector.

Cybersecurity regulation is moving from high-level discussion into implementation.

For blockchain and distributed-ledger ecosystems, that means questions around architecture, decentralisation and immutability must now be considered alongside concrete regulatory obligations relating to product security, lifecycle governance, vulnerability handling and market access.

How the discussion evolved

One theme returned repeatedly during the panel: decentralisation and immutability are sometimes treated within blockchain ecosystems as though they reduce regulatory responsibility.

The discussion moved quickly from that assumption to a more practical question: how organisations can demonstrate lifecycle security, vulnerability management and conformity where the relevant product falls within the Cyber Resilience Act.

The conversation also reflected a wider change in the cybersecurity regulatory landscape.

The issue is no longer simply whether an organisation follows recognised security practices.

For products within scope of the CRA, cybersecurity becomes part of the conditions for access to the European market.

This places greater emphasis on structured, documented and verifiable implementation rather than informal or fragmented security arrangements.

Decentralisation does not remove compliance obligations

One recurring misconception within parts of the blockchain sector is that decentralisation or immutability somehow reduces compliance obligations.

It does not.

The Cyber Resilience Act is technology-neutral.

Where a product falls within its scope, the relevant cybersecurity obligations apply regardless of whether the underlying architecture is centralised, decentralised or based on distributed-ledger technology.

The architecture of a system may affect how security controls are implemented.

It does not, by itself, remove the regulatory obligation.

This distinction is particularly important for blockchain ecosystems, where technical decentralisation can sometimes be confused with an absence of regulatory responsibility.

Security must be demonstrable across the product lifecycle

The CRA requires cybersecurity to be addressed across the lifecycle of products with digital elements.

Security is therefore not limited to the initial design stage.

The compliance framework extends into areas such as:

  • product design and development;
  • vulnerability handling;
  • security updates;
  • remediation processes;
  • technical documentation; and
  • post-market responsibilities.

For blockchain products and infrastructure, this can require organisations to look beyond the security characteristics of the underlying ledger itself.

A system may rely on immutable records or distributed consensus while still containing:

  • software components;
  • interfaces;
  • wallets;
  • APIs;
  • management layers;
  • update mechanisms;
  • third-party dependencies; and
  • other components capable of introducing cybersecurity risk.

The relevant compliance analysis must therefore consider the product as a whole.

Cybersecurity is becoming a condition of market access

One of the most significant consequences of the Cyber Resilience Act is the way cybersecurity becomes connected to access to the European market.

For products within scope, compliance with the CRA’s applicable essential requirements forms part of the regulatory conditions for placing the product on the EU market.

Cybersecurity is therefore no longer only a technical best practice, a contractual expectation or a competitive differentiator.

It becomes part of the product-compliance framework.

For organisations developing blockchain-related products, informal or fragmented security approaches are increasingly difficult to reconcile with that model.

Organisations need structured processes capable of demonstrating:

  • how applicable cybersecurity requirements have been identified;
  • how risks have been assessed;
  • which controls have been implemented;
  • how vulnerabilities will be handled;
  • how the product will be maintained; and
  • how compliance will be evidenced through the relevant conformity-assessment pathway.

From security controls to conformity

Security controls do not operate in isolation from the CRA’s conformity framework.

Manufacturers first need to determine:

  • whether the product falls within the CRA;
  • how it is classified;
  • which essential requirements apply;
  • which standards or technical specifications are relevant; and
  • which conformity-assessment route is available.

This creates an important change in mindset.

Cybersecurity measures need to be capable not only of protecting the product, but also of being documented, assessed and evidenced within a regulatory conformity process.

For blockchain ecosystems, that may require more formal governance than organisations have historically applied to product-security decisions.

The role of European cybersecurity standards

Maria Raphael also contributed perspectives from her work in European standardisation, including her participation in CEN and CENELEC JTC 13.

Within that environment, she has been involved in work concerning horizontal cybersecurity standards supporting implementation of the Cyber Resilience Act.

The role of standards is important because legislation necessarily operates at a relatively high level.

Technical standards can help translate regulatory requirements into more operational and testable specifications.

They can provide a common framework for areas such as:

  • cybersecurity risk management;
  • secure development;
  • vulnerability handling;
  • security controls;
  • lifecycle processes; and
  • conformity evidence.

Horizontal standards are particularly important because they can provide a common cybersecurity foundation that can then be reflected in more product-specific or sector-specific standards.

Standards as a bridge between regulation and implementation

The blockchain discussion highlighted a broader point relevant far beyond distributed-ledger technology.

Regulatory compliance increasingly depends on the interaction between:

  • legal requirements;
  • technical standards;
  • product architecture;
  • security controls;
  • governance processes; and
  • conformity evidence.

An organisation cannot answer a product-security question solely by reading the Regulation.

Equally, technical implementation cannot be separated completely from the regulatory framework governing the product.

Standards increasingly sit between those two layers.

They help provide a common language through which legal cybersecurity requirements can be translated into technical implementation.

CRA and NIS2 address different parts of the cybersecurity landscape

The panel considered both the Cyber Resilience Act and the NIS2 Directive.

The two instruments form part of Europe’s wider cybersecurity framework, but they do not perform the same function.

The CRA focuses on cybersecurity requirements for products with digital elements and the conditions associated with placing relevant products on the European market.

NIS2 focuses on cybersecurity risk-management and incident-related obligations applicable to entities falling within its scope.

For organisations operating blockchain infrastructure, platforms or related services, this can mean that product-level obligations and organisational cybersecurity obligations need to be assessed separately.

Depending on the organisation and the technologies involved, several regulatory frameworks may interact.

The correct compliance model therefore begins with scope analysis rather than assuming that one cybersecurity framework displaces another.

Cybersecurity regulation is becoming part of market strategy

The original Raphael Legal analysis approached cybersecurity and digital regulation not as isolated compliance exercises, but as part of the way products are designed, documented and brought to market.

That remains particularly relevant in the blockchain sector.

The CRA can influence:

  • product architecture;
  • development processes;
  • component governance;
  • vulnerability-management procedures;
  • documentation;
  • conformity assessment; and
  • market-entry planning.

NIS2 can separately affect the organisational cybersecurity framework of entities within scope.

Engaging with this landscape therefore requires more than identifying legal provisions.

Organisations need to understand how regulatory requirements operate in practice, how they interact with technical standards and how they affect the design and operation of products and services intended for the European market.

From decentralised architecture to demonstrable compliance

Blockchain technology may change the architecture of a system.

It does not remove the need to demonstrate compliance with the regulatory requirements that apply to the product or organisation.

For businesses preparing for the CRA and NIS2, the practical challenge is therefore to connect technical architecture with regulatory accountability.

That means moving beyond informal security practices toward structured, documented and verifiable cybersecurity processes.

The panel discussion reflected that shift.

As European cybersecurity regulation moves further into implementation, blockchain organisations will increasingly need to demonstrate not only that their technology is secure, but how that security is governed, maintained and evidenced within the applicable regulatory framework.