How do CER, NIS2 and DORA affect a defence company’s service dependencies?

A defence company may face NIS2 cybersecurity obligations, depend on an operator identified under the Critical Entities Resilience (CER) framework and use financial institutions subject to the Digital Operational Resilience Act (DORA). These relationships do not automatically place it within all three regimes. Assess each essential service through its provider, applicable rules and continuity arrangements.

Service dependencies and CER identification

The first map should describe what the industrial operation needs to keep functioning. Electricity, water, transport, telecommunications, hosted systems and payment services can affect production even when their providers sit outside the immediate defence supply chain. The legal assessment then attaches the relevant regime to each entity and service. Starting with three compliance labels can miss the actual dependency: a plant may have excellent internal controls while relying on one external service that has no workable substitute.

The Critical Entities Resilience framework concerns identified entities providing essential services in specified sectors. It does not make every defence manufacturer a critical entity. Member States assess risks and identify the relevant entities under their national arrangements. The directive required identification by 17 July 2026; that deadline is not evidence that a particular company has been identified. A diligence file needs the applicable national law and any relevant notification or decision, with its date and scope.

CER addresses the ability to prevent, withstand and recover from disruption across natural and human causes. For a defence manufacturer dependent on an identified energy or transport operator, the commercial relevance is the service continuity on which production relies. Regulatory status alone does not specify the manufacturer's restoration priority or guarantee a particular recovery time. The contract, operating arrangements and tested contingencies are needed to determine what the industrial customer can actually expect during a disruption.

NIS2 scope and DORA financial-sector duties

NIS2 has its own sector, size and identification routes, including relevant manufacturing and digital-service categories. It also connects with CER: entities identified as critical under CER are brought within NIS2 regardless of size, subject to the applicable legal provisions. This connection does not erase the two regimes' different purposes or national procedures. A supplier assessment should preserve the legal basis for each obligation and distinguish direct regulatory exposure from security conditions passed through a customer contract.

DORA concerns digital operational resilience in the financial sector and the associated ICT third-party framework. A defence manufacturer does not become a DORA financial entity merely because it borrows from a bank or purchases insurance. Its bank's obligations are relevant to the resilience of the financial service the manufacturer uses. If a group separately supplies ICT services to financial entities, that service relationship requires its own assessment; ordinary lending and ICT outsourcing should not be merged.

Contractual consequences also need a precise causal explanation. A bank may ask a borrower about production continuity as part of credit assessment, while a regulated ICT customer may require specific service, audit and exit terms from its technology provider. These requests have different legal and commercial origins. It would be misleading to describe every resilience covenant imposed on a defence borrower as a direct DORA requirement. The company should identify which obligation applies to which party and which evidence the contract actually requires.

Map common failures and recovery arrangements

An illustrative dependency can cross several regimes without merging them. A production site relies on an external energy operator, a managed-service provider and a bank's payment channel. A disruption could prevent manufacturing, access to production records and timely supplier payment. The resilience review should test those operational effects together, while preserving the separate regulatory status of each provider. Two nominally alternative services may still share a data centre, network route or subcontractor, leaving a common failure point.

The practical output is a service dependency register connected to continuity arrangements. It should identify the provider, responsible internal owner, legal status, contractual commitment, substitute and tested recovery evidence. Significant gaps then become concrete decisions about alternative supply, reserves, contract terms or investment. This approach supports legal compliance and industrial continuity without inventing a single combined defence resilience regime or treating a provider's regulated status as proof that the customer's production is protected.