NIS2 and your
email stack
in 2026.

The most common misreading of NIS2 we have encountered during procurement intake conversations in 2026 is that, because the directive's text does not name email authentication protocols explicitly, the email-sending stack falls outside its scope. This reading does not survive a careful read of Article 21. The article requires "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services" — language that captures email infrastructure with no genuine ambiguity. The ten enumerated measures (risk analysis, incident handling, business continuity, supply-chain security, security in acquisition and maintenance, policies on the effectiveness of risk-management measures, basic cyber hygiene and training, cryptography policy, human-resources security and access control, and the use of multi-factor authentication) each map onto specific controls a sending stack must implement to evidence compliance.

The European Parliament's briefing on NIS2 and ENISA's technical implementation guidance for the implementing regulation on digital infrastructure providers (October 2024) both treat email authentication as an implicit requirement under several Article 21 measures — access control and cryptography in particular, with incident handling running through the analysis where compromise is involved. The implementing regulation goes further for the entities it covers directly (top-level domain registries, DNS providers, certain cloud and data-centre operators), specifying technical controls in thirteen titles. For everyone else, the directive's silence on protocol names is balanced by the regulators' clear position that anti-phishing controls are part of basic cyber hygiene, and basic cyber hygiene is named in Article 21(2)(g).

The practical reading is that the regulator will not arrive with a checklist that says "show me your DMARC record." The regulator will arrive with a request for evidence of how the entity manages risks to network and information systems used for operations. If the answer to that request is silent on email authentication, on incident-response procedures for compromised sending domains, or on supplier security for the email infrastructure, the gap will be identified during the audit and recorded against the entity. That is the dynamic in which Article 21's deliberately broad language produces concrete operational obligations on an email stack — through audits rather than through prescriptive checklists.

NIS2 applies to medium-sized and large enterprises operating in one of the 18 covered sectors (Annex I "highly critical" plus Annex II "other critical"). The size threshold is the standard EU definition: more than 50 employees or annual turnover above €10 million. Either threshold alone brings the entity in scope. Several entity categories are in scope regardless of size, including qualified trust service providers, top-level domain registries, DNS service providers, and providers of public electronic communications networks.

The sectoral coverage is where most organisations discover they are now in scope where they were not under NIS1. Annex I includes energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management business-to-business, public administration, and space. Annex II includes postal and courier services, waste management, chemicals (manufacture and production through to distribution), food production and distribution, manufacturing across multiple sub-sectors — medical devices and electronics, machinery, motor vehicles, plus other transport equipment, digital providers (online marketplaces, search engines, social networking services) and research organisations. The digital infrastructure category under Annex I is particularly expansive in practice: cloud computing service providers, data-centre service providers, content-delivery networks, managed service providers and managed security service providers are all explicitly captured.

The category that produces the most surprise in 2026 is "ICT service management" under Annex I. This captures business-to-business managed service providers — IT outsourcing firms, MSPs running customer infrastructure, and the long tail of SaaS vendors who provide services that other in-scope entities depend on. An MSP managing email infrastructure for a healthcare provider is in scope as digital infrastructure or as managed service provider; the customer is in scope as health; and the obligations flow in both directions through the supply-chain security provisions of Article 21(2)(d). Many MSPs we talked to during 2025 had not realised that their own classification under NIS2 was independent of whether they considered themselves "critical infrastructure" in the colloquial sense.

Organisations operating outside the EU but providing services into the EU are also captured where the activity meets the thresholds. The directive applies extraterritorially to digital service providers under Article 26, and the establishment-based reading for other sectors picks up service into the EU through fixed establishments. The practical question for an organisation that sells into the EU but is headquartered outside is whether it has an establishment in the EU — a branch or other local entity through which the relevant services are provided. If yes, the entity at that establishment is captured by the national transposition that applies there.

One useful sanity check before assuming non-applicability: every organisation we have seen in 2026 that concluded "NIS2 doesn't apply to us" on first read had a service that touched at least one Annex I or II sector through customer relationships. The supply-chain security provisions then make their security posture a documented concern of the in-scope customer, which produces an indirect obligation to evidence the same controls that direct in-scope status would require. Genuine non-applicability is rarer than the first read suggests.

Article 21(2)(a) — Policies on risk analysis and information system security. The email stack needs a documented risk assessment covering the sending domains, the MTA infrastructure, and the inbound flow. The assessment should identify threats specific to email (spoofing of the corporate domain by phishing campaigns, compromise of a sending IP leading to blocklisting, lateral movement from a phishing-clicked endpoint into the wider network) and should record the controls that mitigate each. We have seen entities present a one-page summary and pass; we have seen entities present nothing at all and be issued binding remediation orders. The summary is sufficient if it actually addresses email-specific risks. A generic IT security risk assessment that does not mention email is not.

Article 21(2)(b) — Incident handling. The entity needs a documented incident-response procedure that includes scenarios specific to email: a compromised sending account, a domain hijacked through DNS-provider compromise, a third-party sender on an authenticated subdomain whose practices triggered a blocklist event. Tabletop exercises are not mandatory under the directive's text but are explicitly identified by ENISA's guidance as a control that auditors look for. The procedure should name the on-call who responds within the 24-hour reporting window, and the procedure should have been tested at least once before the audit date.

Article 21(2)(c) — Business continuity. The email stack should have a documented recovery objective. For most entities this means: how long can outbound email be unavailable before the business is materially affected, and what is the failover plan if the primary MTA infrastructure is unreachable. We typically recommend a four-hour recovery time objective for transactional flows and a twenty-four-hour objective for marketing flows, with documented failover to a secondary sending region. The directive does not specify thresholds, so the entity sets its own — but the threshold needs to be documented and the failover needs to have been tested.

Article 21(2)(d) — Supply-chain security. This is the measure that captures the email-vendor relationship most directly. The directive requires entities to assess the security of their direct suppliers and service providers, including the quality of cybersecurity practices and the supplier's own NIS2 compliance status where applicable. For an entity using a managed email provider, this means the provider needs to be able to evidence its own controls — typically through a current DPA, a sub-processor list, a description of its security organisation, and an indication of whether it is itself an in-scope NIS2 entity. We cover supply-chain mechanics in more depth in section 05.

Article 21(2)(e) — Security in network and information systems acquisition, development and maintenance. The acquisition language matters for procurement: when the entity selects a new email vendor or renews an existing contract, security has to be a documented evaluation factor. We see this evidenced through a procurement-evaluation document that scored vendors on security and through DPA negotiations that record the points the entity contested. Vulnerability handling and disclosure is also captured here — the entity should have a documented process for handling CVEs in the email-stack software (MTA, anti-spam, DKIM signers) and for receiving vulnerability reports from third parties via security.txt or an equivalent channel.

Article 21(2)(f) — Policies and procedures to assess the effectiveness of risk management. The entity needs evidence that its email-security controls are tested and that the test results feed back into the risk assessment. For most entities this means a regular review of DMARC aggregate reports (to confirm authentication coverage), a review of inbound anti-phishing detections (to confirm filtering is operating), and a review of access logs to the MTA admin plane (to confirm administrative access is constrained). Quarterly review is a defensible cadence; monthly is better for organisations under any active regulatory pressure.

Article 21(2)(g) — Basic cyber hygiene and cybersecurity training. The training requirement applies to staff but should specifically address phishing. We have not yet seen a 2026 audit where phishing training was absent and the entity was not flagged. The training does not need to be sophisticated — annual delivery via the entity's normal LMS, with a documented completion rate above 90 %, is the floor. Below that, the entity becomes a documented finding.

Article 21(2)(h) — Cryptography policy. The email stack needs to evidence TLS in transit (opportunistic STARTTLS is the floor, MTA-STS plus DANE is the production standard), DKIM signing on every sending domain, and a cryptography policy that names the key lengths and supported algorithms along with the rotation cadence. The 2024 transition to RSA-2048 for DKIM is the practical baseline; ed25519 is acceptable where the entity has validated downstream compatibility. We rotate DKIM keys on a six-month cadence by default and document the rotation procedure.

Article 21(2)(i) — Human-resources security, access-control policies and asset management. The administrative interface to the MTA needs role-based access control, with separate accounts for operations and audit, and removal of access on offboarding. Shared admin credentials are a finding. Bearer-token API access without rotation is a finding. The audit will ask who has the keys to the sending infrastructure and how the answer is updated when the headcount changes.

Article 21(2)(j) — Use of multi-factor authentication. Multi-factor authentication is mandatory for administrative access to the email stack. This is the most prescriptive of the ten measures: where the others use "appropriate and proportionate" language, MFA is named directly. The standard production posture in 2026 is hardware-token MFA (WebAuthn-class) for production access, with TOTP as the fallback. SMS MFA is acceptable as a tertiary fallback but is no longer the production standard for most regulators.

Article 23 of NIS2 establishes a three-stage reporting obligation that triggers on a "significant incident" — defined as one that has caused or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The early-warning notification must reach the national CSIRT within 24 hours of the entity becoming aware. A more detailed incident notification follows within 72 hours, with an initial assessment of severity and impact. A final report follows within one month.

The 24-hour clock is the tightest part of the obligation and the part most entities have not operationally rehearsed. The clock starts on awareness, not on confirmation. An entity that suspects a sending domain has been compromised at 02:00 on a Saturday cannot wait until Monday morning to assess whether the suspicion is well-founded before making the early-warning call. The directive expects the early warning to be made on the basis of available information at the time, with an explicit statement of whether the incident appears to be the result of unlawful or malicious acts and whether it could have cross-border impact.

For an email-sending stack, the scenarios that trigger reporting are narrower than the scenarios that trigger an incident-response procedure. A blocklist event affecting one IP and resolved within an hour is not a significant incident. A phishing campaign impersonating the corporate domain that successfully reached customers and resulted in fraud is. A compromise of the MTA admin plane that allowed an attacker to send mail under the entity's authenticated domains for any non-trivial period is unambiguously a significant incident and triggers the full reporting cascade. A DNS-provider compromise that affected DKIM key publication and resulted in legitimate mail failing authentication at scale sits at the boundary; most national CSIRT guidance issued in 2025 suggests treating boundary cases as reportable.

The operational implication is that an entity needs a documented escalation path that can produce the early-warning call within 24 hours from any point in the calendar. On-call rotations need to include someone with the authority to make the decision, not just the technical capacity to assess the indicators. We have seen entities miss the 24-hour window because the engineer who detected the incident escalated to a manager who was on holiday, whose escalation contact was on parental leave, whose own escalation contact had moved roles. The reporting obligation does not pause for organisational change.

One member-state quirk worth flagging: Cyprus has implemented a six-hour early-warning requirement in its national transposition, materially tighter than the directive's 24-hour minimum. Entities with operations in Cyprus that are reportable under Cypriot transposition cannot rely on the 24-hour figure when designing their escalation paths. Other member states have stayed at 24 hours but several have added clarifying language about what counts as "awareness" that has the effect of starting the clock earlier than entities expected. The Italian transposition treats awareness as triggered by any senior operational role, not just the security organisation, which has produced earlier clock starts than the directive's text alone would suggest.

Supply-chain security under NIS2 is the measure most likely to reshape the procurement landscape for managed email in 2026. The directive requires entities to consider "the specific vulnerabilities" of each direct supplier and service provider and "the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures." For an entity that has delegated outbound email to a managed provider, this language puts the provider's security posture inside the entity's compliance perimeter — which is to say, the entity needs to be able to evidence the provider's controls during its own audit.

The minimum vendor-evidence package we now see auditors expect is composed of four documents. The first is a current data-processing agreement that names the parties, the categories of data, the sub-processor chain, and the security measures the processor commits to. The second is a sub-processor list with jurisdictions named — auditors in 2026 are specifically asking which sub-processors are established in third countries and how third-country government access is mitigated, which connects the NIS2 audit to the Schrems II analysis the entity already had to perform under GDPR. The third is a description of the provider's security organisation that names the security lead, the incident-response contact, and the audit cadence applied to the provider's own controls. The fourth is a position on the provider's own NIS2 status — whether the provider is in scope, in which member state, under which classification.

The fourth document is the one that most managed email providers we encountered in 2026 had not yet produced. A provider that is itself in scope as a digital-infrastructure entity under Annex I, operating under a transposed national law, is a stronger supply-chain position than a provider in the same business who has concluded it is not in scope. The reason is straightforward: if the provider is itself regulated, the customer can cite that fact in its own supply-chain evidence and the audit work is partially substituted. If the provider is not in scope, the customer needs to perform a parallel assessment to demonstrate the provider meets the equivalent standard. Providers who clarify their own status save their customers compliance work, which has become a procurement factor.

For our own positioning: BIG BOX Hosting d.o.o. is in scope as a digital-infrastructure provider under the Slovenian transposition of NIS2 [VERIFY: Law no. XX/2025], classified as an Important entity given headcount and turnover. Our sub-processor list names only entities established in EU or EEA jurisdictions, which addresses the third-country access analysis at the supply-chain layer. Customers using our managed services can cite our status in their own audit evidence. This is a deliberate procurement-side outcome of the structural choices we made on jurisdiction and sub-processing.

As of May 2026, twenty-one of the twenty-seven EU member states have transposed NIS2 into national law. The European Commission sent a reasoned opinion on 7 May 2025 to nineteen states that had missed the October 2024 deadline; most of those states have since enacted their transpositions. Spain and Portugal — alongside a handful of smaller states — remained in late draft as this guide went to press. The Commission's January 2026 amendment package proposed targeted simplifications affecting around 28,700 companies, but the basic architecture of the directive has not changed.

The divergence between transpositions matters most for cross-border entities that operate in multiple member states. The directive sets minimum standards but explicitly permits member states to go further. Three areas of divergence have produced concrete operational consequences in 2026.

Reporting timelines. Cyprus requires the early warning within six hours, a quarter of the directive's 24-hour floor. Several Baltic states have implemented additional reporting checkpoints between the 72-hour notification and the one-month final report. The Italian transposition has clarified the awareness trigger in ways that effectively bring the start of the clock earlier. An entity with operations in any of these states needs the escalation path engineered against the local rule, not the directive's text.

Sectoral scope. Member states have discretion to apply NIS2 to smaller entities where a national assessment finds those entities critical. Spain's transposition explicitly extends scope to certain sub-threshold entities in the energy sector. The Polish transposition adds entities below the size threshold where their role in supply chains to in-scope entities is judged material. The directive's size-cap therefore does not produce identical scope across the EU.

Supervisory and registration mechanics. The German NIS2UmsuCG took effect on 6 December 2025 and gave entities until 6 March 2026 to register with the BSI through its dedicated portal. The Austrian Network and Information System Security Act 2026 was transposed on 23 December 2025 with entry into force on 1 October 2026, and entities have three months from entry into force to register. The Italian framework relies on the National Cybersecurity Authority (ACN) and the technical annexes are still being issued in 2026. Each of these mechanics has a different practical impact on the date by which an entity must be evidence-ready.

The pragmatic approach we have recommended to customers running operations across more than one member state is to build the evidence pack against the strictest of the applicable transpositions and to inherit the resulting controls everywhere else. An entity that can show six-hour escalation for Cyprus operations will not be challenged on 24-hour escalation in another state. An entity that can show registration with the BSI and a current contact-point notification will not be challenged on the equivalent registration in a state with a less mature portal. Defending against the strictest applicable rule is a cheaper compliance posture than defending against each rule separately.

The financial penalty ceilings under NIS2 are set at the directive level and member states cannot transpose lower (though several have transposed higher). Essential entities face administrative fines of up to €10 million or 2 % of total worldwide annual turnover, whichever is greater. Important entities face up to €7 million or 1.4 %. These ceilings are aligned with GDPR's enforcement posture, which the EU legislators explicitly framed as the intended comparison during the directive's drafting.

The headline numbers obscure the part of the enforcement framework that has actually changed procurement-side behaviour in 2026: management bodies are personally accountable under Article 20. The management body approves the cybersecurity risk-management measures, oversees their implementation, and can be held personally responsible for failures. For Essential entities, competent authorities have the additional power to temporarily prohibit individuals responsible for management functions from exercising their duties where they have failed to comply with remediation orders. This is the provision that has produced the most board-level engagement we observed during 2025 and 2026.

The non-financial enforcement tools are also more material than the fines suggest. National authorities can issue binding instructions, mandate independent audits at the entity's cost, impose temporary service restrictions, and publicly disclose non-compliance findings. For most regulated entities, the reputational hit of a public non-compliance notice is a larger commercial concern than the fine ceiling, particularly where the entity sells into the public sector or into industries with their own procurement-side compliance requirements. We have seen procurement teams in the German Mittelstand explicitly ask, during 2026 vendor selection, whether a candidate vendor has been the subject of any published NIS2 finding. A "yes" is a deal-blocker independent of the underlying fine amount.

The interaction with GDPR enforcement is worth flagging briefly. A single incident — say, a phishing campaign that resulted in unauthorised access to personal data — can trigger both NIS2 reporting and GDPR breach notification, with parallel investigations by the cybersecurity competent authority and the data-protection authority. Fines under both frameworks are not stacked automatically (the principle of ne bis in idem applies under EU constitutional law) but the directive permits parallel enforcement and the practical outcome is two investigations, two evidence requests, and two reputational events. Operating with a unified evidence pack that satisfies both frameworks at once is the only sustainable posture.

The first wave of formal NIS2 audits has produced enough empirical data for some patterns to be visible. The auditors we have observed work through a fairly consistent inventory of requests, with the exact sequencing varying by member state but the underlying questions converging. The list below is the evidence pack we now recommend customers assemble before the 30 June 2026 audit deadline for Essential entities.

1. Registration confirmation. The national portal confirmation that the entity has registered and that the contact-point details are current. For Germany this is the BSI portal record; for Austria it will be the equivalent under the 2026 Act. Auditors ask for this first because it confirms the entity has acknowledged its in-scope status.

2. The risk assessment. A current risk assessment that names the email infrastructure as a covered asset and identifies email-specific threats. Date of last review and the owner should be on the document, with the next review date also recorded. A risk assessment older than twelve months is a finding in itself.

3. The incident-response playbook. The procedure that produces the 24-hour notification in practice. Auditors specifically ask to see the most recent tabletop-exercise record or, where the entity has had a real incident, the post-mortem. An incident-response procedure that has not been exercised reads as aspirational rather than operational.

4. The DMARC and SPF records, plus MTA-STS. A printout of the current DNS records for the sending domains, with the DMARC policy at p=reject (or at p=quarantine with a documented timeline to reject), SPF aligned, and MTA-STS published with a current TLSA record for DANE where applicable. Auditors in 2026 are checking actual DNS, not relying on the entity's self-report.

5. The aggregate DMARC report review. Evidence that the entity is processing aggregate DMARC reports and that authentication coverage is at or above 98 % for legitimate sending sources. Below 98 % is not automatic failure but does prompt follow-up questions about the long tail of unauthenticated mail.

6. The sub-processor list and DPAs. A current sub-processor list for every email-stack vendor, with jurisdictions named and the corresponding DPAs available. For each sub-processor in a third country, the documented analysis of transfer mechanism (adequacy decision, standard contractual clauses, or supplementary measures) and the position on third-country government access risk.

7. The access-control inventory. Who has administrative access to the MTA, who has API access to the sending service, what MFA is enforced, and how access is reviewed. A current inventory dated within the last quarter is the floor.

8. The cryptography policy. The policy that names DKIM key length, rotation cadence, TLS configuration, and the cipher suites supported on the MTA edge. Practical implementation should match the policy.

9. The training records. The most recent phishing-training completion record, with completion percentage and the date of the last training campaign. Below 90 % completion produces follow-up questions.

10. The most recent management-body review. Minutes or equivalent record of a management-body discussion of NIS2 compliance, dated within the last twelve months. Article 20 makes this evidence material, and auditors specifically ask for it.

An entity that can produce these ten documents on request is not guaranteed to pass an audit, but it is unlikely to be issued a binding remediation order. An entity that cannot produce them is at the other end of the distribution. The middle ground — partial documentation, out-of-date records, undocumented practices that may or may not be in place — is where most of the early enforcement activity has landed in the first half of 2026.

DORA-specific obligations for financial-services entities. The Digital Operational Resilience Act applies to the EU financial sector from 17 January 2025 and overlaps with NIS2 in important ways. Where both apply, DORA's lex specialis status means the financial-services-specific obligations control. This guide treats NIS2 as the baseline; entities under DORA need to read the September 2023 Commission Guidelines on the relationship between the two frameworks and treat the DORA-specific incident-reporting and ICT third-party risk-management obligations as the operative rules.

National security and defence carve-outs. The directive does not apply to entities carrying out activities in national security or public security, nor to defence or law enforcement. Where an in-scope entity has a defence-related business line, the scope question becomes fact-specific and member-state-specific. This guide does not attempt to address those carve-outs; entities in that situation need legal advice in the specific member state.

The Cyber Resilience Act. The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027. It governs cybersecurity requirements for products with digital elements and is a separate regime from NIS2 (which governs operational security of entities). An entity that both operates digital infrastructure and manufactures products with digital elements is subject to both, but this guide does not cover the CRA.

Audit-firm selection. For Essential entities approaching the 30 June 2026 audit deadline, the choice of audit firm matters operationally. We do not recommend specific audit firms in this guide. The competent authority in each member state publishes a list of qualified audit organisations under its national transposition. Engaging a firm that has done at least one NIS2 audit before is materially preferable to engaging a firm doing its first.