Selling into Europe? Cybersecurity Requirements U.S. Companies Need to Assess

U.S. companies usually encounter European cybersecurity expectations in one of three ways. First, a law may apply directly to an entity, activity or product. Second, an EU subsidiary, importer, distributor, regulated customer or other commercial customer may pass requirements through the supply chain or contract. Third, a company may voluntarily adopt an assessment or assurance framework before any customer mandate to support market access, evidence reuse or trust.

Those routes are not interchangeable. A useful readiness review therefore labels every requirement as direct legal scope, customer or contractual flow-down, or voluntary assurance choice. That distinction prevents both under-reaction and expensive over-compliance.

Start with the business trigger, not the acronym

Searches such as “Does NIS2 apply to U.S. companies?” are reasonable starting points, but they are too broad for a reliable conclusion. Begin by identifying why the question has appeared.

Does NIS2 apply to U.S. companies?

Sometimes—but not merely because a company has customers in Europe. NIS2 is a directive. Its operative obligations are applied through Member State law, so a final scope conclusion must identify the relevant national implementation as well as the directive-level framework.

At directive level, Article 2(1) covers public or private entities of a type listed in Annex I or II that meet the relevant medium-size threshold or exceed it and provide services or carry out activities within the Union.[1] Article 2 also contains size-independent cases, including specified communications, trust, DNS and domain-registration services, entities identified because of criticality or systemic impact, and other defined situations.[1]

For a specific set of digital providers—DNS services, TLD registries, domain registration services, cloud computing, data centres, content delivery networks, managed services, managed security services, online marketplaces, online search engines and social-networking platforms—Article 26 establishes special jurisdiction rules. For those provider categories, an entity that otherwise falls within the scope of NIS2 and is not established in the Union but offers the relevant services within the Union must designate a representative in the Union.[2]

That is narrower than the claim that every non-EU vendor is directly subject to NIS2. A U.S. manufacturer, professional-services firm or SaaS company outside those categories may still be affected through an EU establishment, a covered activity under national law, another group entity, or customer and supply-chain requirements. The facts determine the route.

Why suppliers still receive NIS2 questionnaires

Article 21 requires in-scope essential and important entities to implement appropriate and proportionate technical, operational and organisational measures. The minimum areas include supply-chain security and the security-related aspects of relationships with direct suppliers and service providers.[3] In-scope entities must consider supplier vulnerabilities and the overall quality of suppliers’ products and cybersecurity practices, including secure development procedures.[3]

This does not automatically turn every supplier into an NIS2-regulated entity. It does explain why an EU customer may ask a U.S. supplier for risk, incident, continuity, access-control, secure-development and assurance evidence—or place corresponding obligations in the contract.

Explore A-R-C support for NIS2 governance and evidence readiness →

Does DORA apply to U.S. vendors?

Most U.S. ICT vendors should first expect customer due diligence and contractual flow-downs—not assume that they are directly supervised under DORA.

DORA Article 2(1) lists the covered financial-sector entities in points (a) to (t) and ICT third-party service providers separately in point (u); Article 2(2) defines only points (a) to (t) collectively as “financial entities”.[4] The regulation therefore includes ICT third-party providers in its scope, but it does not impose every financial-entity obligation on every vendor. Financial entities remain responsible when they use ICT third parties. They must manage ICT third-party risk, maintain a register of ICT contracts and, before entering into an arrangement, conduct due diligence and identify and assess relevant risks, including potential ICT concentration risk. For ICT services supporting critical or important functions, they must also put in place exit strategies.[5]

That responsibility changes what EU financial customers require from vendors. Article 30 requires written allocation of rights and obligations and, depending on the service, provisions covering:

• the functions and ICT services supplied, including permitted subcontracting;
• the countries or regions where services are delivered and data is processed or stored;
• availability, authenticity, integrity and confidentiality of data;
• data access, recovery and return;
• service levels and incident-related assistance;
• cooperation with competent and resolution authorities;
• termination, transition and exit;
• for critical or important functions, detailed reporting, contingency testing and access, inspection and audit rights.[6]

A U.S. vendor can therefore face substantial DORA-related requirements even when the vendor itself has not been designated as a critical ICT third-party service provider.

Critical ICT third-party providers are a separate case

The European Supervisory Authorities designate critical ICT third-party service providers using the criteria in Article 31. A third-country provider designated as critical must establish an EU subsidiary within 12 months following designation if EU financial entities are to continue using its services.[7] The Oversight Framework and the Lead Overseer’s powers apply to those designated critical providers; they do not apply automatically to every vendor serving a bank or insurer.

The practical question for an ordinary vendor is usually: Can we satisfy our financial customer’s due-diligence, contract, assurance, incident, subcontractor and exit requirements without making claims we cannot support?

Read the detailed A-R-C analysis of DORA and software-provider responsibility →

Does the EU Cyber Resilience Act apply to U.S. software companies?

Headquarters location is not the decisive test. The Cyber Resilience Act (CRA) applies to products with digital elements made available on the EU market when their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.[8]

A “product with digital elements” includes software or hardware and its remote data-processing solutions. Remote data processing is included where it was designed and developed by or under the manufacturer’s responsibility and the product could not perform one of its functions without it.[9] That wording does not make every stand-alone professional or cloud service a CRA product; the product and service architecture must be classified carefully.

The CRA contains exclusions and interactions with sector-specific regimes, including certain medical devices, in-vitro diagnostics, motor-vehicle products, aviation products, marine equipment, defence or national-security products and specified spare parts.[8] Open-source treatment also requires a separate analysis of whether software is supplied outside or in the course of a commercial activity.

What manufacturers need to prepare

Manufacturer obligations include a documented product cybersecurity risk assessment, secure design and development, due diligence for integrated components, vulnerability handling, a support period, technical documentation, conformity assessment, an EU declaration of conformity, CE marking where required, user information and corrective action for nonconformity.[10]

The calendar matters:

• CRA Chapter IV, concerning notification of conformity-assessment bodies, applies from 11 June 2026.
• Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.
• The regulation generally applies from 11 December 2027.[11]

Under Article 14, the initial notification deadline for an actively exploited vulnerability or severe incident is without undue delay and in any event within 24 hours after the manufacturer becomes aware of it, followed by additional information under the statutory sequence.[12] For a manufacturer with no main establishment in the Union, Article 14(7) determines the Member State endpoint, based on the information available to the manufacturer, in this order: the Member State where the authorised representative acting for the highest number of the manufacturer’s products is established; then the importer placing the highest number of those products on the market; then the distributor making the highest number available; and finally the Member State where the highest number of users is located. The notification is submitted through the single reporting platform to the relevant coordinating CSIRT and is simultaneously accessible to ENISA.[12]

A useful readiness project therefore connects product security, engineering, vulnerability operations, legal classification, market access and management accountability. A policy-only exercise is not enough.

Do U.S. automotive suppliers need TISAX?

TISAX is usually encountered as a customer and supply-chain requirement, not as a law that automatically applies to every automotive supplier.

The official ENX Participant Handbook describes the typical supplier as fulfilling a customer requirement. The supplier registers as an active participant, is assessed and shares the assessment result with the requesting partner.[13] TISAX uses assessment objectives, assessment results and TISAX labels; it should not be presented as a generic statutory obligation or casually renamed “TISAX certification”.

A U.S. engineering, technology, prototype, logistics or professional-services supplier may be asked for TISAX when handling information with protection needs for a German or European automotive customer. The correct first questions are:

• Which customer requested the assessment, and which assessment objectives did it specify?
• Which legal entities, locations, people, systems and services handle the relevant information?
• Does the customer expect the standard scope or, exceptionally and after consultation with the audit provider, a custom extended scope or a full custom scope explicitly accepted by the customer?
• Which evidence already exists, and which gaps affect assessment readiness?

Explore A-R-C TISAX readiness support for suppliers and service providers →

Can NIST CSF, SOC 2 or ISO 27001 evidence be reused?

Yes—often substantially. But reuse requires a controlled crosswalk.

NIST describes the Cybersecurity Framework as a way to help organisations understand and improve the management of cybersecurity risk.[14] CSF 2.0 provides governance and outcome language that can support a common internal model. ISO/IEC 27001 defines requirements for an information security management system.[15] SOC 2 reports can provide scoped descriptions and assurance evidence about selected controls over a defined period.

None of those artefacts automatically proves legal scope, CRA product conformity, a TISAX assessment objective or every DORA contract requirement. Common failure modes include:

• mapping control names but not checking scope, ownership or evidence freshness;
• treating a SOC 2 report period as proof of current operating effectiveness everywhere;
• assuming an ISO 27001 certificate covers products, subsidiaries or locations outside its stated scope;
• using NIST outcomes as if they were one-to-one legal requirements;
• ignoring customer-specific contractual duties, reporting windows and audit rights.

A defensible evidence crosswalk records the target requirement, existing control, accountable owner, evidence, scope, test status, exception and remaining decision. It should expose gaps rather than hide them behind framework labels.

What cybersecurity evidence will European customers request?

The exact request depends on sector and service, but the following evidence families appear repeatedly in regulatory and customer assurance work:

See A-R-C audit-readiness and evidence support →

A practical 30-day readiness path

1. Map the European business trigger. Identify products, services, customers, EU entities, importers, distributors, regulated sectors and customer deadlines.
2. Classify the route. Mark each issue as potential direct legal scope, national-law question, customer/contract flow-down or voluntary assurance choice.
3. Build one evidence inventory. Collect NIST profiles, SOC 2 material, ISO scope, policies, risk records, product-security artefacts, contracts and customer questionnaires.
4. Crosswalk without declaring equivalence. Link each target requirement to owners, controls and evidence; record gaps, exceptions and legal questions separately.
5. Prioritise blocked business outcomes. Address the contract, market-entry milestone, product release or customer renewal that created the demand.
6. Create a 90-day implementation roadmap. Assign owners, decisions, dependencies, acceptance evidence and escalation paths.

This sequence is deliberately shorter than a full compliance programme. Its purpose is to establish scope, reuse defensible evidence and prevent teams from launching several disconnected framework projects.

Frequently asked questions

Related A-R-C resources

Primary and authoritative sources

1. European Parliament and Council, Directive (EU) 2022/2555 (NIS2), Article 2 and Annexes I–II. Official EUR-Lex text (accessed 17 July 2026).
2. NIS2, Article 26, jurisdiction and territoriality, especially Article 26(1)(b) and 26(3).
3. NIS2, Article 21(1)–(3), cybersecurity risk-management and supply-chain security.
4. European Parliament and Council, Regulation (EU) 2022/2554 (DORA), Article 2. Official EUR-Lex text (accessed 17 July 2026).
5. DORA, Article 28, general principles for ICT third-party risk.
6. DORA, Article 30, key contractual provisions.
7. DORA, Article 31, designation of critical ICT third-party service providers, especially Article 31(12).
8. European Parliament and Council, Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 2. Official EUR-Lex text (accessed 17 July 2026).
9. Cyber Resilience Act, Article 3(1)–(2), definitions of product with digital elements and remote data processing.
10. Cyber Resilience Act, Article 13, manufacturer obligations.
11. Cyber Resilience Act, Article 71, staged application dates.
12. Cyber Resilience Act, Article 14, manufacturer reporting obligations.
13. ENX Association, TISAX Participant Handbook, sections 3 and 4, including active/passive participant roles and the assessment process. Official handbook (accessed 17 July 2026).
14. National Institute of Standards and Technology, Cybersecurity Framework 2.0. Official NIST resource centre (accessed 17 July 2026).
15. International Organization for Standardization, ISO/IEC 27001:2022 — Information security management systems. Official ISO overview (accessed 17 July 2026).