Salesforce NIS2 Compliance: What Shield, Identity, and MFA Cover Under Article 21(2)(h)-(j) – And the Policy Gap They Leave

Type “Salesforce NIS2 compliance” into a search engine and you get vendor backup pitches and generic SaaS-risk blog posts. None of them open Article 21(2) next to a live Salesforce org and ask the only question that matters for an auditor: which specific Shield feature satisfies which specific letter of the Directive, and where does the platform’s job end and your organisation’s paperwork begin? That gap is what this guide closes.

Salesforce Shield’s three components — Platform Encryption, Event Monitoring, and Field Audit Trail — map cleanly onto Article 21(2)(h) cryptography and the CIR 2024/2690 Annex’s Section 9. Salesforce Identity and the platform’s 2026 multi-factor authentication mandate map onto Article 21(2)(i)-(j) and Annex Section 11. But a technical control and a documented policy are not the same deliverable, and the second one is what a competent authority actually asks to see. With most EU member states now enforcing their national transposition, that distinction has moved from theoretical to auditable.

Does NIS2 Even Apply to Your Salesforce Org?

In plain terms: if your organisation is an essential or important entity under NIS2, Article 21 obligations sit with you, not with Salesforce. Salesforce’s own compliance site lists certifications but does not mention NIS2 or a shared-responsibility model for it anywhere on that page [1]. That silence is not an oversight — it’s the correct legal position. The Directive regulates your organisation’s network and information systems; Salesforce is a supplier your organisation is contractually responsible for governing under Article 21(2)(d)’s supply chain security measure, a topic covered separately in our cloud supply-chain security guide.

There’s a second, narrower scoping question worth flagging for CISOs and compliance officers doing the technical reading: the CIR 2024/2690 Annex — the detailed technical specification this article maps Salesforce features against — is legally binding only on a specific list of digital-infrastructure providers (DNS/TLD registries, cloud computing providers, data centres, CDNs, managed service and managed security providers, online marketplaces, search engines, social platforms, and trust service providers) [2]. A CRM SaaS platform sits in a genuinely ambiguous position on that list, and most organisations reading this article are bound by Article 21(2) directly rather than by the CIR. Use the Annex sections below as the interpretive benchmark for what “appropriate” measures look like — not as a checklist your auditor can cite chapter and verse against you. Not sure whether your organisation is in scope at all? Start with our NIS2 scope test.

Salesforce Shield and Article 21(2)(h): Encryption Is a Feature, a Cryptography Policy Is a Document

Article 21(2)(h) requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption” [1]. CIR Annex Section 9 spells out what that policy has to contain: documented selection of cryptographic algorithms and key strengths appropriate to the data, plus a key management process [2][3][4].

Shield’s Platform Encryption delivers the technical half. It applies 256-bit AES encryption across standard and custom fields, and it supports customer-controlled key material — the org can set, store, and fetch its own key information rather than relying solely on Salesforce-managed keys [7]. That satisfies the mechanism Section 9 assumes exists. It does not satisfy Section 9 itself, because Section 9 is a documentation requirement: a written policy stating which data classifications require encryption, which algorithm and key length were chosen and why, and who owns key rotation and destruction. Buying Shield and turning on encryption for a few sensitive fields, with no record of that decision process, is the exact gap an auditor is trained to probe — a control with no rationale on file.

Where teams get this wrong is treating “where appropriate” as optional. It isn’t a loophole; it’s a requirement to document why a given field is or isn’t encrypted, not a licence to skip the analysis entirely. See our dedicated cryptography and encryption policy guide for the full Section 9 breakdown.

Event Monitoring, Field Audit Trail, and CIR Section 3.2’s Logging Requirement

The Directive’s logging obligation actually sits inside Article 21(2)(b) incident handling, not (h) — a distinction worth getting right, since CIR Annex Section 3.2 (“Monitoring and Logging”) requires the entity to lay down procedures and tools to monitor and log activity specifically so it can detect incidents, and to set alarm thresholds that trigger a timely, qualified response [3][4].

Event Monitoring covers the detection half well: it tracks more than 50 event types — logins, API calls, report exports, permission changes — stored as EventLogFile records accessible via API, the Event Log File Browser, or the Event Monitoring Analytics app [7]. Field Audit Trail adds the historical record, tracking up to 60 fields per object with retention of up to 10 years, without counting against org storage limits [7]. Together they give you the raw log data Section 3.2.3 expects.

What they don’t give you is Section 3.2.4’s alarm-and-response layer. EventLogFile access is API-driven and largely retrospective by default — someone has to build the alerting rules, define the thresholds that count as anomalous, and document who responds and how quickly. A 10-year audit trail that nobody reviews until an incident has already happened satisfies the letter of “logging” and misses the point of the measure entirely. Our logging and monitoring procedure guide walks through building that response layer on top of whatever platform generates the logs.

Salesforce Identity, the 2026 MFA Mandate, and Article 21(2)(i)-(j)

Article 21(2)(i) covers “human resources security, access control policies and asset management”; 21(2)(j) covers multi-factor or continuous authentication [1]. Both sit under CIR Annex Section 11 (Access Control), which requires a documented access policy, periodic access reviews, privileged-account management, unique user identification, and multi-factor or continuous authentication specifically for critical systems [2][3][4][5].

Salesforce moved the baseline here significantly in 2026: MFA enforcement for all internal users rolled out to production orgs from 20 July 2026, and privileged users — admins specifically — face an additional requirement to use phishing-resistant methods such as passkeys or hardware security keys rather than SMS or app-based one-time codes [6]. SSO users can no longer substitute a weaker non-Salesforce second factor for step-up authentication [6]. That closes a gap Section 11.7’s emphasis on stronger authentication for privileged and critical-system access specifically anticipates.

What the platform mandate doesn’t do is write your access policy. Section 11 also asks for a documented review cadence (who re-certifies access and how often), a current privileged-account inventory, and unique-identity assignment across every integration user and API key — not just human logins. Salesforce Identity handles the SSO and provisioning mechanics; the review schedule and the inventory are your organisation’s artefacts to produce. See our access control policy guide and MFA requirements guide for what that documentation needs to contain.

Hyperforce EU Data Residency Doesn’t Solve Your Supply-Chain Question

Salesforce’s Hyperforce EU Operating Zone commits to storing and processing customer data within the 27 EU member states and restricts support staff to EU-based personnel [8]. For a compliance officer weighing Article 21(2)(d) supply-chain risk, that sounds like it settles the jurisdiction question. Salesforce’s own FAQ says otherwise: EU OZ “does not address all of the legal issues raised in the Schrems II case,” because Salesforce remains a US-headquartered provider subject to CLOUD Act jurisdiction regardless of where the servers physically sit [8]. A handful of features — certain Einstein capabilities among them — are disabled inside EU OZ precisely because they’d otherwise move data outside the EU [8].

That’s a genuine, disclosed limitation, not a marketing gap — and it belongs in your supplier risk assessment rather than being assumed away because a region selector says “EU.” Our supply chain security guide covers how to document that kind of residual risk for a Article 21(2)(d) supplier record.

Notice the pattern repeating across all three sections above: Salesforce ships the mechanism, and the CIR Annex asks for the reasoning behind it in writing. That’s not a Salesforce-specific shortfall — it’s the structural difference between a SaaS platform’s job (run the control) and a regulated entity’s job (justify and evidence the control) — but it’s exactly where audits find gaps, because the mechanism is easy to demo and the paperwork is easy to postpone.

The Full Mapping, at a Glance

Salesforce feature	Article 21(2)	CIR Annex section	Salesforce provides	Your org must still document
Shield Platform Encryption	(h) Cryptography	Section 9	AES-256 encryption, customer-controlled keys	Written crypto policy: classification-to-algorithm mapping, key rotation owner
Event Monitoring + Field Audit Trail	(b) Incident handling	Section 3.2	50+ event log types, up to 10-year field history	Alarm thresholds, response-time targets, who reviews logs
Identity + platform MFA mandate	(i)/(j) Access control, MFA	Section 11	SSO, enforced MFA, phishing-resistant methods for admins	Access review cadence, privileged-account inventory, unique IDs for integration users
Hyperforce EU OZ	(d) Supply chain	Section 5 (by analogy)	EU-region storage and support access	Documented CLOUD Act / Schrems II residual-risk assessment

Frequently Asked Questions

Is Salesforce itself required to comply with NIS2? Only if Salesforce falls within one of the specific digital-infrastructure categories CIR 2024/2690 names directly bound entities from — a genuinely unsettled question for a CRM SaaS platform. Either way, your organisation’s Article 21 obligations don’t depend on the answer: you’re responsible for how you configure and govern Salesforce as a supplier.

Does turning on Shield automatically make our Salesforce org compliant? No. Shield gives you the technical controls Article 21(2)(h)-(j) assume exist. The written policies, the access-review schedule, and the alarm/response procedures the CIR Annex asks for are documentation your organisation has to produce and maintain separately.

Do smaller Salesforce Essentials or Starter orgs need Shield to comply? Not necessarily — Article 21(2) uses proportionate, risk-based language throughout. A smaller org processing lower-sensitivity CRM data may be able to justify lighter encryption and monitoring measures, provided that decision is itself documented as part of the risk assessment, rather than left unaddressed.

What about Experience Cloud portals with external customer or partner logins? The 2026 MFA enforcement changes are scoped to internal users; external Experience Cloud identities are explicitly excluded from that mandate and remain an optional setting admins configure themselves [11]. That configuration — and the reasoning behind whichever second-factor requirement you set for external users touching regulated data — is exactly the kind of access-control documentation Section 11 expects, and it’s easy to overlook precisely because the platform doesn’t force it the way it now forces MFA for internal logins.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• NIS 2 Directive (EU) 2022/2555, Article 21 — nis-2-directive.com
• CIR 2024/2690 Annex, Section 9 & Section 11 — nisd2.eu
• CIR 2024/2690 Annex mapping (independent cross-check) — OpenKRITIS
• CIR 2024/2690 Annex mapping (independent cross-check) — Advisera
• “NIS2 Article 21 Decoded” — NIS2-Templates.com
• Salesforce MFA enforcement update, 2026 — Salesforce Help
• Salesforce MFA enforcement scope for Experience Cloud users, 2026 — Salesforce Help
• “Your Comprehensive Guide to Salesforce Shield” — Varonis
• Hyperforce EU Operating Zone FAQ — Salesforce Help
• Salesforce Compliance Site — compliance.salesforce.com