Device control decides what can plug into a company machine and what happens when it does. Most teams treat it as a USB switch. It is closer to a policy about every physical path in and out.
The short answer
Device control is the endpoint capability that governs removable media and peripherals: USB drives, external disks, phones in storage mode, SD cards, Bluetooth, printers and more. It enforces what each class of device is permitted to do on a managed machine, and it records what happened. It closes the physical path that network controls cannot see.
The reason it still matters in a cloud-first company is simple. Every other control assumes data moves over a network you can inspect. A USB drive does not.
On this page
What device control governs
The category is wider than removable storage, which is where most policies stop and most gaps appear.
| Device class | The risk it carries |
|---|---|
| USB mass storage | The obvious one. Bulk copy out, or malware in, with no network record either way |
| Phones in storage mode | A charging cable that is also a data path, which policies written for USB sticks routinely miss |
| External and portable drives | Large capacity, easy to lose, and rarely encrypted unless enforced |
| SD cards and card readers | Frequently excluded from policies that name USB explicitly |
| Bluetooth | File transfer and input devices, wireless and therefore invisible to a cable-based policy |
| Printers and scanners | Paper is an exfiltration format and a scanner is an ingestion one |
| Optical and legacy media | Rare, but still enumerated in PCI DSS and audit questionnaires |
The four enforcement modes
Device control is not a switch. Treating it as one is why policies get disabled within a month of deployment.
Read only is the underused answer
Most business objections to device control are about getting files in, not out: a client hands over a drive, a contractor brings assets, someone restores from a backup. Read only permits all of that while closing the exfiltration path. Teams that jump straight to full block generate an exception queue, and an exception granted under deadline pressure is rarely reviewed again.
Device control and DLP
They overlap and are often confused. The distinction is that one asks about the destination and the other asks about the content.
| Device control | DLP | |
|---|---|---|
| Question it answers | Can this device connect and write? | Can this specific data leave? |
| Decision basis | Device class, serial, user group | File content, classification, destination |
| Strength | Absolute on the physical path, and simple to evidence | Granular, and covers cloud and network paths too |
| Weakness | Blunt. It cannot tell a customer database from a holiday photo | Depends on classification quality, and needs tuning |
| Deployment effort | Policy set once, largely static | Ongoing, because rules follow how data actually moves |
Run both. Device control handles the path that carries the highest volume with the least visibility, and it does so on day one. DLP handles everything that leaves over a network, and it takes longer to get right.
Where frameworks require it
| Framework | What it expects |
|---|---|
| PCI DSS | Controls over removable media holding cardholder data, including handling, storage and secure destruction |
| ISO 27001 | Annex A controls for storage media management and endpoint device protection |
| SOC 2 | Restriction of physical and logical access to data, evidenced across the observation window |
| HIPAA | Device and media controls, covering disposal, re-use, movement and accountability |
| DPDP Act | Reasonable safeguards over personal data, which extends to the media it can be copied onto |
| RBI and SEBI frameworks | Restrictions on removable media for regulated entities, with usage logging |
The evidence request is consistent across all of them: the policy, proof it is enforced technically rather than written down, and a log showing exceptions and who approved them. A policy document with no enforcement behind it is the finding auditors write most often here.
How Osto handles device control
Device control runs from the same agent as the rest of the endpoint stack, alongside antimalware and application control, disk encryption and screen lock policy. Policy applies by device class and by user group rather than as one global setting, so the finance team and the engineering team can differ without an exception process.
Because it shares a stack with everything else, the events land in the same SIEM as identity, cloud and application activity. A blocked write attempt on its own is minor. The same user hitting it repeatedly, days after their access was reviewed, is a pattern worth seeing, and that only surfaces when endpoint and identity events sit in one place. Coverage and exception reporting map into the GRC evidence base without a separate export.
Platform walkthrough
Close the path you cannot inspect
Device policy by class and by group, enforced from the same agent that runs antimalware, encryption and file access controls. One owner, one dashboard.
Book a demoEnforcement evidence built in · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is device control?
An endpoint capability that governs which removable media and peripherals can connect to a managed machine and what they are permitted to do. It covers USB storage, external drives, phones in storage mode, SD cards, Bluetooth and printers, and it logs activity for audit.
Is device control the same as blocking USB ports?
No. Blocking is one of four modes. The others are read only, allow listing specific approved hardware by serial, and permitting with logging. Read only is usually the most workable position, because it permits files in while closing the path out.
What is the difference between device control and DLP?
Device control decides whether a device can connect and write, based on device class and user group. DLP decides whether specific data can leave, based on content and classification. Device control is blunter and faster to deploy. DLP is granular and covers network paths too.
Do we need device control if all our data is in the cloud?
Yes, because data reaches endpoints in order to be used. Exports, local downloads and cached files all sit on machines with physical ports. Cloud storage moves where data lives, not where it can be copied from.
What evidence do auditors want for device control?
The policy, proof of technical enforcement rather than a written rule, coverage across in-scope devices, and a record of exceptions with who approved them and when they were last reviewed.