Removable Media Under NIS2: The One Prohibition in CIR 2024/2690 Is a Default USB Block — What 12.3.2 Requires and the Evidence to Keep

Short answer: if your organisation falls under Commission Implementing Regulation (EU) 2024/2690, your removable media policy must block USB storage by default. Annex point 12.3.2(a) requires “a technical prohibition of the connection of removable media unless there is an organisational reason for their use”. Writing “USB sticks are not allowed” in a policy does not meet that. The block has to be enforced on the endpoint, with a documented route for exceptions.

That one clause is rarer than most compliance guides suggest. We searched the full text of the regulation, and the word “prohibit” appears exactly once: in 12.3.2(a). Across thirteen Annex chapters of risk-management requirements, this is the only clause written as a prohibition. The NIS2 Directive itself never mentions removable media or USB at all.

One disclosure up front: we sell policy templates, so weigh our view with that in mind. Below we quote the regulation and ENISA’s guidance directly, show which parts of 12.3 leave you room to decide and which do not, and list the evidence worth keeping.

Does this apply to you?

In plain terms: every NIS2 entity has to manage its assets, and USB drives are assets. Only eleven digital-sector entity types are bound by the exact wording of Annex 12.3. For everyone else it is the most detailed public benchmark of what “asset management” means for removable media.

The underlying duty sits in Article 21(2)(i), which lists “human resources security, access control policies and asset management”. Chapter 12 of the CIR Annex is headed “Asset management (Article 21(2), point (i))”, and 12.3 is its third section.

Your organisation	Where the obligation comes from	Is Annex 12.3 the legal test?
DNS provider, TLD registry, cloud provider, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network, trust service provider	National law transposing Article 21, plus CIR 2024/2690 (directly applicable)	Yes. The wording quoted below is binding.
Any other essential or important entity (energy, health, transport, manufacturing, public administration…)	National law transposing Article 21(2)(i)	No, but a supervisor reviewing your asset management may use it as a benchmark
Not in NIS2 scope	No NIS2 duty	No, though it remains sound practice

Not sure which row you are in? Check Article 1 of the regulation first. If your service type is not on that list, your national transposition act is the text to read.

What 12.3 actually requires, clause by clause

In plain terms: three of the four duties in 12.3.2 carry no “where appropriate” qualifier. You cannot argue them away on proportionality grounds. Only encryption is optional, and skipping it has to be justified in writing.

That matters because of Article 2(2) of the regulation. Where the Annex says “where appropriate”, “where applicable” or “to the extent feasible”, an entity that decides not to apply the point “shall in a comprehensible manner document its reasoning”. Points without those qualifiers don’t offer that route. The only flexibility in 12.3.2(a) is the one built into the clause itself: the organisational reason.

Point	What the text says	Qualifier	What it means in practice
12.3.1	Establish, implement and apply a removable media policy and communicate it to employees “and third parties who handle removable storage media” at your premises or wherever the media connects to your systems	None	Contractors, maintenance engineers and colocation staff must receive the policy too, not just employees
12.3.2(a)	“a technical prohibition of the connection of removable media unless there is an organisational reason for their use”	None (exception built in)	Default-deny enforced on endpoints; every exception tied to a stated business reason
12.3.2(b)	“disabling self-execution from such media and scanning the media for malicious code before they are used”	None	Autorun off everywhere, plus a malware scan before first use of any permitted device
12.3.2(c)	“controlling and protecting portable storage devices containing data while in transit and in storage”	None	Custody rules: locked storage, tracked handover, a loss procedure
12.3.2(d)	“where appropriate, provide measures for the use of cryptographic techniques”	“Where appropriate”	Encrypt, or document under Article 2(2) why you don’t
12.3.3	Review “at planned intervals and when significant incidents or significant changes to operations or risks occur”	Update “where appropriate”	Set an interval yourself, and add a trigger: any incident involving media reopens the policy

Two details are easy to miss. First, ENISA’s Technical Implementation Guidance lists the removable media policy as one of ten topic-specific policies it says must be documented. ENISA adds that the format is up to you: a separate document, an update to an existing policy, or one combined document. Second, ENISA’s guidance is softer than the regulation on scanning. It says media “should be scanned for malicious code, where appropriate”, while the binding text of 12.3.2(b) has no such qualifier. ENISA calls its own guidance non-binding, so if you are a CIR entity, follow the regulation’s wording.

Why the regulation asks for both autorun-off and scanning

In plain terms: turning off autorun stops a drive from launching code when it’s plugged in. It does nothing when a person double-clicks a malicious file. Scanning covers that second route, which is why 12.3.2(b) asks for both.

The Raspberry Robin worm shows the two routes side by side. In its October 2022 analysis, Microsoft reported nearly 3,000 devices in almost 1,000 organisations with at least one Raspberry Robin payload alert in a 30-day window. The worm spread on USB drives through a shortcut (LNK) file disguised as a folder. Microsoft’s researchers confirmed both infection paths in real attacks: some drives carried a configured autorun.inf, while others relied on a user clicking a shortcut named after a USB drive brand.

The same analysis explains why autorun is still a live issue. Microsoft notes that autorun of removable media “is disabled on Windows by default. However, many organizations have widely enabled it through legacy Group Policy changes.” So the operating system default proves nothing on its own. Point 12.3.2(b) turns “autorun off” into a setting you have to show is enforced on every endpoint.

Scanning has a second job too: document-borne malware. Reporting on Honeywell’s 2024 USB Threat Report, Industrial Cyber notes that about 20% of the malware Honeywell analysed was content-based. Over 13% exploited the normal features of everyday files such as Word documents, spreadsheets and scripts. These numbers come from one vendor’s data on USB threats to industrial environments, so treat them as a direction rather than a census. The direction is still clear: a spreadsheet passed on a USB stick never needs autorun to run its payload.

Defining the “organisational reason”: the exception register

In plain terms: the regulation lets you allow removable media when there is an organisational reason, but never defines one. Your policy has to define it, and every exception should leave a record.

The phrase “organisational reason” appears once in the whole regulation and comes with no examples. ENISA’s guidance only says the policy should include “authorization requirements” and usage guidelines. The most useful concrete model comes from the US: NIST SP 1334 (September 2025) recommends “prohibiting media usage unless expressly authorized”, with authorisation “limited to specific personnel and purposes”. It also says media from outside sources should be treated as untrusted, and that logs should record “system and user identity, device serial number, date and time”.

Built on that, an exception register entry that can stand up to review usually holds:

• Who: a named user or role, never “IT department”
• Which device: serial number or device ID, so one approval doesn’t quietly cover every drive of the same model
• Which systems: the endpoints or network segment where the device may connect
• What operation: read only, or read and write; execution from the media stays blocked
• Why: the organisational reason in one sentence (firmware updates on an isolated network, evidence handover to an auditor, a court filing)
• Until when: an expiry date and an approver

Scope is wider than USB sticks. ENISA’s footnote to 12.3 brings personal devices into the policy “if personal devices are used to store corporate data”, which links this policy to your BYOD policy requirements. The same footnote adds that vehicles which store data locally or share it through telematics “are also included”. External hard drives, SD cards, optical media and phones mounted as storage all belong in the definitions section.

How to enforce the block: settings that produce evidence

In plain terms: the best control is one that blocks the device and leaves a log at the same moment. Here is how the 12.3.2 duties map to common enforcement points, with rough effort estimates.

Duty	Typical control	Evidence it produces	Effort
12.3.2(a) default block	Endpoint device control set to deny removable storage, with allow rules for registered device IDs	Exported policy, block and allow event logs	Medium
12.3.2(b) self-execution off	AutoPlay and AutoRun disabled by central policy for all drives	GPO or MDM configuration report showing the setting on every endpoint	Low
12.3.2(b) scanning	On-access scanning by endpoint protection, or a dedicated scanning station for OT and isolated networks	Scan logs tied to device serial numbers	Low (IT) / High (OT)
12.3.2(c) transit and storage	Locked storage, labelled and inventoried devices, custody log for handovers	Asset register entries, sign-out log	Medium
12.3.2(d) encryption	Allow write access only to encrypted devices	Device control rule plus encryption policy	Low to Medium

On Windows estates, Microsoft documents most of this natively. Device control in Microsoft Defender for Endpoint supports exactly the 12.3.2(a) pattern: preventing the use of any external devices “with specific exceptions”, or allowing only BitLocker-encrypted devices, which also covers point (d). For self-execution, the AutoPlay policy settings include “Turn off AutoPlay” and a default AutoRun behaviour setting that can “completely disable autorun commands”. Raspberry Robin’s mitigation list adds an attack surface reduction rule that blocks untrusted and unsigned processes running from USB. macOS and Linux fleets need the same three controls through their MDM or endpoint tool, so check what your vendor supports before you write the policy.

Operational technology is the hard case. Engineering workstations often can’t run modern agents, and vendors arrive with their own media. NIST SP 1334 suggests disabling unnecessary ports logically (BIOS, operating system, group policy) or physically (port locks, epoxy), write-protecting media that only needs to be read, scanning before and after use, and scanning from an approved alternate device when the target system can’t run a scanner. In OT, that scanning station is usually how you meet 12.3.2(b).

The evidence auditors ask for

In plain terms: ENISA publishes example evidence for each sub-point, and an assessor checking 12.3 is likely to work from that list. Two items carry an “if any”, which tells you ENISA expects some entities to have little to show for them.

Point	ENISA example evidence	Where gaps usually show
12.3.1	Documented policy covering at least the 12.3.2 items; user instructions; training records or signed acknowledgements; awareness campaigns	Third parties never received the policy
12.3.2	Endpoint protection configuration settings (“if any”); audit logs of insertion, removal and data transfer; reports of incidents involving removable media (“if any”)	Logs exist but nobody can link a log entry to a register exception
12.3.3	Up-to-date policy; records of reviews or history of changes	No review after a lost-media incident

The acknowledgement piece rarely needs its own form. If your staff already sign an acceptable use policy, put the removable media rule and the exception route in it. One signature then covers both. Logging is also where removable media overlaps with data loss prevention evidence, since the same insertion and transfer logs serve both.

Responsibility usually splits like this:

• CISO or IT security lead: owns the device control policy, the AutoRun setting and the log pipeline. Consider running the block in audit mode first, so you see which business processes still depend on USB before enforcement stops them.
• Compliance officer: owns the exception register and the review record, and writes down the Article 2(2) reasoning if encryption is not applied somewhere.
• SME owner: the minimum workable version is one policy page, one central setting that blocks storage devices, a handful of encrypted approved drives, and a spreadsheet register.
• Board: approves the policy as part of the topic-specific policy set and receives incident reports involving lost media.

The stakes are the general Article 21 ones. Under Article 34, Member States must allow fines for infringing Article 21 with a maximum of at least €10,000,000 or 2% of total worldwide annual turnover for essential entities, and at least €7,000,000 or 1.4% for important entities, whichever is higher. National law may set higher maxima.

Frequently asked questions

Does NIS2 ban USB drives?

No. The Directive never mentions them. For the eleven entity types covered by CIR 2024/2690, point 12.3.2(a) requires a technical block by default, with use allowed where there is an organisational reason. That is a default-deny rule with exceptions, not an outright ban.

Is a written policy enough without a technical control?

Not for CIR entities. The text says “technical prohibition”, and it requires the policy to “provide for” it. A policy that only tells staff not to plug things in leaves 12.3.2(a) unmet.

Do we need encryption on every approved drive?

Encryption is the only 12.3.2 point marked “where appropriate”. You can decide not to use it for some media, such as read-only firmware drives with no sensitive data, but Article 2(2) requires you to document that reasoning. Allowing writes only to encrypted devices is the simplest way to stay on the safe side.

Where does this sit if we follow ISO 27001?

ISO/IEC 27002:2022 has a control titled 7.10 Storage media, with malware protection under 8.7. That is the natural home in an ISO-based ISMS. Check that your 7.10 implementation says “blocked by default” and covers third parties, because the CIR wording is explicit on both points.

Does the policy belong in the asset management procedure?

It can. ENISA leaves the format open, and 12.3 sits inside the asset management chapter. Our asset management guide shows how the five chapter 12 duties fit together, including the inventory where approved devices should be recorded.

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

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex. Articles 1 and 2(2); Annex chapter 12 heading and points 12.3.1, 12.3.2 and 12.3.3. Linked in the introduction.
2. Directive (EU) 2022/2555 (NIS2 Directive), full text — EUR-Lex. Linked in the introduction.
3. NIS2 Directive, Article 21 — Cybersecurity risk-management measures (nis-2-directive.com, primary text).
4. NIS2 Directive, Article 34 — General conditions for imposing administrative fines (nis-2-directive.com, primary text).
5. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025. Topic-specific policy list; guidance, footnote 105 and examples of evidence for points 12.3.1–12.3.3.
6. NIST Special Publication 1334, Reducing the Cybersecurity Risks of Portable Storage Media in OT Environments — NIST NCCoE, September 2025.
7. Device control in Microsoft Defender for Endpoint — Microsoft Learn.
8. Policy CSP – AutoPlay — Microsoft Learn.
9. Raspberry Robin worm part of larger ecosystem facilitating pre-ransomware activity — Microsoft Security Blog, 27 October 2022.
10. Honeywell’s 2024 USB Threat Report reveals significant rise in malware frequency — Industrial Cyber, 30 April 2024.
11. ISO/IEC 27002:2022, Information security controls — preview edition (contents), controls 7.10 and 8.7.