NIS2 guide · 7 min
Vendor impersonation and CEO-fraud (BEC): email spoofing, DMARC and NIS2
One of the most common supply-chain attacks needs no breach at all: an attacker sends email that appears to come from a supplier (or from you) and redirects a payment or steals data. This is business email compromise (BEC) and vendor impersonation, enabled by weak email authentication that anyone can check from the outside. Under NIS2 you are accountable for the security of your supplier relationships (Article 21(2)(d)), and email spoofability is one of the clearest, cheapest signals to fix. This guide explains how the attack works, the SPF, DKIM and DMARC settings that stop it, and how it fits NIS2.
Key takeaways
- • BEC and vendor impersonation exploit weak email authentication, not a technical breach.
- • SPF, DKIM and an enforced DMARC policy block spoofed mail, and they are publicly checkable.
- • Under NIS2 this is part of supplier-relationship security, and it protects both you and your suppliers.
How vendor impersonation and BEC work
The attacker does not need to hack anyone. If a domain does not enforce email authentication, they can send mail that appears to come from it: a fake invoice with new bank details 'from your supplier', or an urgent request 'from your CEO'. The recipient trusts the familiar sender and acts. Because suppliers and customers email each other constantly, one weak domain in the chain becomes everyone's problem. NIS2 Article 21(2)(d) makes managing this relationship risk your responsibility.
Official source: NIS2 Directive on EUR-Lex — Article 21(2) (security measures, incl. secure communications) and 21(2)(d) (supply-chain security).
The controls that stop spoofing
These are standard, free to deploy in DNS, and publicly verifiable. They map to the Article 21(2) baseline for secure communications and to how the attack actually works.
SPF (Sender Policy Framework)
Publishes which servers may send mail for your domain. Without it, or with an over-permissive record, spoofed senders pass unchecked. Publish SPF and keep it accurate as you add mail services.
DKIM (DomainKeys Identified Mail)
Cryptographically signs your outgoing mail so receivers can verify it was not altered and truly came from your domain. Enable DKIM on every service that sends as you.
DMARC with an enforced policy
Ties SPF and DKIM to your visible From address and tells receivers what to do with mail that fails. A policy of p=none only monitors; move to p=quarantine or p=reject to actually block spoofing.
DMARC reports (rua) and monitoring
Aggregate reports show who is sending as your domain, so you can find your legitimate senders before enforcing and spot abuse afterwards. Route the reports somewhere they are read.
MTA-STS and TLS reporting (extra hardening)
Enforce encrypted delivery to your domain and get told when it fails, closing a downgrade path an attacker can otherwise use to intercept mail.
See how your suppliers actually score
7-day free trial · no credit card · cancel anytime
Why this matters under NIS2, for you and your suppliers
Enforced email authentication protects your customers and partners from being defrauded in your name, and protects you from a supplier's spoofed invoice. Because it is externally visible, it is exactly the kind of signal a customer checks when assessing you as a supplier under NIS2, and what an attacker probes first. Continuous monitoring of your own domain and your suppliers surfaces a weak or drifting DMARC policy (for example one still at p=none) and maps it to the Article 21(2)(d) supply-chain duty, so it is fixed before it is exploited.
Common mistakes
- ✕Publishing DMARC at p=none and never moving to enforcement, so nothing is actually blocked.
- ✕SPF or DKIM on the main domain but not on subdomains or third-party sending services.
- ✕Assuming a supplier's invoice email is genuine because the sender name looks right.
- ✕No process to verify a payment or a change of bank details out of band.
You don't have to read the reports yourself
DMARC aggregate reports are daily XML files, and nobody wants to read them by hand. norppa.io receives them for you at a unique reporting address, turns them into pass-rate analytics and a sender inventory, and raises active spoofing sources as prioritised findings. TLS-RPT reports are handled the same way. EU-hosted, aggregate data only, included in every plan.
See how your email posture maps to NIS2
A sample supplier report (findings, NIS2 mapping and evidence) in two minutes.
7-day free trial · no credit card · cancel anytime
Related guides
How to comply with NIS2: a step-by-step roadmap
The steps to NIS2 compliance in order: confirm scope, register, management accountability (Art. 20), the Article 21(2) measures, supply-chain security, incident reporting (Art. 23) and continuous, evidenced assurance.
Who is in scope for NIS2? Essential vs important entities, sectors and size thresholds
Determine whether NIS2 applies to you: the two tiers, the Annex I/II sectors, the size thresholds, size-independent exceptions, and how the supply chain pulls you in even if you're not designated.
NIS2 for suppliers: you're not designated, but your customers are
Most companies are never designated under NIS2, yet many must comply anyway. How a covered customer's Article 21(2)(d) supply-chain duty flows down to you, what they'll ask for, and how to respond credibly.
NIS2 and the supply chain requirement: what it means in practice
NIS2 requires essential and important entities to assess their supply chain cyber risks. Supplier tiering, 4th-party risk, Art. 23 notification, and what auditors look for.
Supplier cyber risk assessment: what automated NIS2 monitoring checks
All check categories explained: ransomware, dark web leaks, TLS/DNSSEC, cookie security, CVE/EPSS, sanctions, MX blacklists and SAQ. Finding lifecycle and NIS2 article mapping.
NIS2 Art. 21(2): supplier security checklist
Checklist for procurement and security teams: what to ask, what evidence to collect, and how to respond when a supplier falls short. Includes suggested evidence documents.
NIS2 supplier questionnaire (SAQ): what to ask, how to score it, and a free template
What to ask suppliers under Art. 21(2)(d), how to score answers and respond to gaps, why self-attestation needs verification, and a free copy-paste questionnaire template.
NIS2 incident reporting: the 24- and 72-hour deadlines explained
What counts as a significant incident, the Article 23 timeline (24-hour early warning, 72-hour notification, one-month final report), and when a supplier's incident becomes your obligation.
NIS2 and management responsibility: what boards and leadership must know
What NIS2 expects of the management body: approval and oversight duties, personal liability (Art. 20), training, board reporting KPIs, and the penalties under Art. 34.
ISO 27001 and NIS2: what your ISMS already covers, and the gaps it doesn't
If you hold ISO 27001, what carries over to NIS2 and what does not: statutory incident reporting, management liability, registration, and continuous supply-chain assurance: plus how to close the gap.
NIS2 fines and penalties: how much, who is liable, and how to avoid them
What NIS2 penalties are: the Article 34 caps (€10M / 2% for essential, €7M / 1.4% for important entities), the management body's personal liability (Art. 20, Art. 32), non-monetary enforcement, and how to avoid them with continuous, evidenced diligence.
NIS2 vs DORA: how they differ, where they overlap, and which one applies to you
How the two EU regimes differ and overlap, why DORA is lex specialis for financial entities, which applies to you, and what both mean for third-party and supply-chain risk.
GDPR vs NIS2: how they overlap, where they differ, and when one incident triggers both
How GDPR and NIS2 differ and overlap, when one incident triggers both (GDPR Art. 33 72h to the DPA vs NIS2 Art. 23 24h/72h/1-month to the CSIRT), the Art. 35 cooperation and no-double-fine rule, and what both mean for supplier due diligence.
The EU Cyber Resilience Act (CRA): scope, timeline and what it means for your supply chain
What the CRA requires, its phased dates (in force 2024, reporting Sept 2026, full compliance Dec 2027), who is in scope and why pure SaaS often isn't, how it complements NIS2, and what it means for procurement and supplier due diligence.
The EU AI Act: risk tiers, the timeline, and what deployers must do (Article 26)
What the EU AI Act requires: the risk tiers, the phased dates (in force 2024, prohibited Feb 2025, GPAI Aug 2025, high-risk Aug 2026), the Article 26 deployer obligations, how it stacks with NIS2 and the GDPR, and what it means for AI procurement.
NIS2 transposition status: which EU countries have it in force
Which of the 27 EU Member States have written NIS2 into national law and which are still finalising it, and why the gaps reach your supply chain regardless.
NIS2 supplier contract clauses: what to require from your suppliers
The contract clauses that turn NIS2's supply-chain duty into something enforceable: security baseline, incident-notification window, evidence and audit rights, subcontractor flow-down, and how to verify them continuously.
Your external security posture under NIS2: what suppliers and customers can see
The publicly visible signals customers assess under NIS2 Art. 21(2)(d): email spoofability (SPF/DMARC), certificate hygiene, internet-exposed systems and leaked credentials, why each matters and how to check and fix them.
Do your suppliers use AI? NIS2 supplier risk meets the EU AI Act
Suppliers increasingly embed AI in the services you depend on, and so do their suppliers. Where supplier and nth-party AI creates risk under NIS2 Art. 21(2)(d) and the EU AI Act, what to assess, and how to keep visibility.
Last reviewed: 19 June 2026
This guide is general information about EU law, not legal advice. NIS2 takes effect through each EU Member State's national transposition law, which can differ in detail. Verify the obligations that apply to you with your competent authority or legal counsel.