DLP software here covers one half of data loss prevention: the exits. USB storage, remote desktop and remote terminal are closed by signed company policy on the endpoint, and every blocked attempt comes back as a signed audit record with the device serial number on it. It does not read your files and it does not classify them.
Classic DLP has two halves. One reads the file: content inspection, pattern matching, a classifier that decides a spreadsheet is confidential. The other watches the channel: which routes out of a machine are open at all, and for whom.
The rule usb-port-blocking restricts mass storage and imaging by Windows device class. The drive does not mount, and the keyboard, the mouse, the audio, the network adapter and the Bluetooth radio carry on.
The rule remote-desktop-blocking closes the remote desktop path, scoped at gateway, user or device level. It does not read the screen.
The rule remote-terminal-blocking closes the remote terminal path, with the same scope and the same signature. It does not inspect commands.
Of the 16 rules in the catalogue, those three are the exits, and each one is signed in the console before it reaches a device. How policy is scoped and signed is a page of its own.
This is the second half, and only the second half. No inspection engine, no classification, no library of patterns hunting for card numbers. If a file is allowed to leave, nothing reads it on the way out.
Press the panel and plug three things into the same laptop. No port is switched off and nothing is recabled. What changes is what the machine accepts.
The diagram reads left to right. On the left, Company Policy holds three exit rules, usb-port-blocking, remote-desktop-blocking and remote-terminal-blocking, scoped at gateway, user or device level and signed before they leave the console. The signed policy travels down the policy channel to a Windows endpoint in the middle, where the system service checks the signature against a pinned key and the application only passes the bytes through. On the right is what the machine accepts once the rule is in force, in three groups. Restricted by class: mass storage and imaging. Untouched: keyboard, mouse, audio, network adapter and Bluetooth. Closed by rule: remote desktop and remote terminal. Along the bottom, a refused attempt returns to the console as a signed audit record carrying the vendor ID, the product ID, the USB class, the description and the serial number, inside a timestamp window of plus or minus 30 seconds. The three buttons plug a storage stick, a keyboard and a remote session into the same machine: the storage stick and the remote session are refused and leave a record, the keyboard carries on and leaves none. Nothing here reads the contents of a file.
The console signs the rule before it leaves. On the machine the app is transport, not authority: it passes the bytes through as they arrived, and the checking happens in the system service against a pinned key. There is no settings file on the laptop where somebody writes themselves an exception.
“We do not allow USB drives” is a sentence in a document, and a document proves intent. It does not say what any machine actually did.
Work from the port instead of the device class and the keyboard goes off with the drive. The list of approved exceptions starts the same afternoon, and it never gets shorter.
One Windows machine with an open USB port, an open remote desktop path and an open shell. Data leaves by whichever is nearest.
With nothing coming back from the device, the first news that a copy left the building is a person mentioning it.
USB Guard works from Windows device class identifiers instead of switching ports off, so mass storage and imaging get restricted while the keyboard, the mouse, the audio, the network adapter and the Bluetooth radio carry on.
And before it changes anything, the client captures the configuration it found, so the machine goes back exactly as it was.
“We do not allow USB drives” is a sentence in a document, and a document proves intent.
What lands in the console is a dated list of attempts, each with a vendor ID, a product ID, a USB class, a description and a serial number. That is what the assessor wanted.
Rules apply at gateway, user or device level, and a device override only changes the ids it sets. Everything else still comes from the level above.
The app is transport, not authority: it passes the bytes through as they arrived, and the checking happens in the system service against a pinned key. There is no settings file on the laptop where somebody writes themselves an exception.
A watch thread inside the process re-asserts the policy against devices that appear afterwards, so plugging a stick in at six in the evening is not a way around it.
Each blocked connection arrives as its own signed audit record, in a timestamp window of plus or minus 30 seconds. USB behaviour, mode by mode, is next door.
Everywhere else in the catalogue a soft mandate means on by default, and the person at the desk may switch it off. On usb-port-blocking it is inverted.
It runs one way, and only one way:
The inversion is on purpose. The state you land on while distracted is the safe one.
Reactive is armed on this rule. A critical alert revokes the VPN rather than filing a notification.
On the rules where it is not armed, the interface says so in an amber note. You read which is which on the rule, not in a matrix somebody wrote for a brochure.
Same machine, same ports. Storage and imaging restricted by class, remote desktop and remote terminal closed by rule, keyboard and headset untouched.
A watch thread inside the process re-asserts the policy against devices that appear afterwards, so the hour somebody chooses is not a way around the rule.
Your evidence stops being a policy document and becomes a dated list of attempts, each one carrying a vendor ID, a product ID, a USB class, a description and a serial number.
Through the platform instead of around it. Direct transfer runs inside the tunnel, the recipient consents before anything arrives, and refusal is the default.
These are not a related links box. Each one owns a piece of the same rule, and the order is the order the rule travels.
Scopes the rule at gateway, user or device level and signs it before it leaves the console. Three of its 16 rules are the exits on this page.
The USB exit on its own, mode by mode, including what the audit record carries and what the allowlist does not do yet.
The way through the platform once the port is closed: transfer inside the tunnel, consent on receipt, and refusal as the default.
The agent that holds the rule, checks the signature in the system service, and carries the anti-ransomware shield next door.
The wider job this belongs to is the endpoint protection use case, and every feature is listed in one place.
No content inspection, no data classification, no library of patterns hunting for card numbers. If a file is allowed to leave, nothing reads it on the way out.
No email or webmail control and no browser upload control. Somebody photographing a screen is not a problem this solves. If that is the requirement, a classic DLP suite is the tool and this is not pretending to be one.
The control works at the level of the device class, not the individual device. There is no way to say that these three encrypted drives are fine and the rest are not.
USB Guard is in production on Windows, on the roadmap for Linux, and planned MDM-assisted for macOS. The client itself already runs on macOS and Android, which is a different statement and we would rather write both than tick a row.
The anti-ransomware shield closes Documents, Pictures and Desktop to any program it does not recognise: those processes read, but never modify, overwrite, delete or rename. That is data being destroyed, not data being copied out.
No cloud and no sync. They live on the machine, which is worth knowing before anybody counts them as a way to move a document between two people. What else the agent does is on the client page.
DLP software stops sensitive data leaving an organisation. Classic suites read files and classify their contents. This one closes the exits: USB storage, remote desktop and remote terminal, blocked by signed policy, with every attempt recorded.
It is the channel half of data loss prevention. If the requirement says to classify documents and block them by content, this does not meet it. If it says removable storage must not work and you have to prove it, this does.
No. The control works at the level of the device class, not the individual device.
Through the platform instead of around it. Direct transfer runs inside the tunnel, the recipient consents before anything arrives, and refusal is the default.
An engineer, a console shaped like yours, and as long as you need. You watch the drive stop mounting while the keyboard keeps typing, then watch the record come back with the serial number on it. It is free and there is nothing to sign.
