GiliSoft USB Lock controls how a Windows computer accepts removable storage and other connected-device channels. An administrator can block reading from a USB drive, block writing to it, or allow only devices recorded in a trusted list. The same policy area can restrict memory cards, optical discs, phone data transfer, tethering, Bluetooth, printers, and selected ports. GiliSoft USB Lock changes access on the computer; it does not encrypt the files on a flash drive or make that drive private on another machine.
Read and write split
USB storage has separate read and write controls. Blocking writes can stop users from copying computer files onto removable storage while leaving approved reference material readable. Blocking reads prevents the computer from opening files on the device. Activating both creates a full storage block.
The distinction matters during setup. A user may still see a drive letter but fail to save a file when only writing is disabled. A phone may continue charging while its data-transfer channel remains blocked. Test the action the policy is meant to stop instead of judging the result from whether a device receives power or appears in Windows.
Trusted drives need records
The whitelist lets approved company drives work while unknown storage stays restricted. To build it, the administrator inserts each trusted drive and adds its device identity. GiliSoft USB Lock can export the completed list and import it on other managed computers.
The list follows the recorded hardware, not the label printed on the case. Replacing a failed drive with the same model does not guarantee the new unit has the same identity. Add the replacement, export a fresh list, and redeploy it where necessary. Test one trusted drive and one unlisted drive after every import.
Device classes overlap
Controls beyond storage can restrict phones, card readers, disc drives, printers, modems, infrared, Bluetooth, and COM, LPT, or 1394 ports. These are broad device channels. Disabling every USB controller at the operating-system level can also interrupt keyboards, mice, webcams, or printers, which is why the product separates storage restrictions from wider device locks.
Enable only the channels required by the policy. A rule intended to stop file copying may need USB writing and phone transfer blocked, but it may not need printer or Bluetooth restrictions. Broad deployment before a small test can leave a shared computer without a peripheral that staff still need.
Policies need a restart
GiliSoft USB Lock stores control settings behind an administrator password. Its managed-control guide requires a restart after applying the device settings. Open files on removable media should be closed first; otherwise, the policy change can interrupt access while another program still expects that file to remain available.
Reconnecting a device also helps Windows apply a changed rule. If an approved drive remains blocked, check whether the correct physical device is in the whitelist and whether reading, writing, or both remain disabled. The activity log can identify the rule that denied the connection.
Recovery needs preparation
Initial setup requires a master password, and the official guide advises adding a recovery email before restrictions spread to other computers. Losing the administrator password without a prepared recovery path can turn an ordinary policy change into a support problem. Store the recovery details away from the controlled workstation.
A temporary-password process can grant authorized access without revealing the permanent administrator password. Temporary access does not change the underlying whitelist or device policy permanently. When the allowed period ends, the managed restrictions apply again.
Logs explain events
Logs record allowed devices, denied attempts, and policy events. They can show that a connection was blocked and which rule acted, but they do not prove what a person intended to copy. Review the device identity, time, and active policy together.
GiliSoft USB Lock also has website and program restrictions. Those controls extend beyond removable-media management, so they need their own test plan. A device rule that behaves correctly does not confirm that a blocked-site redirect or program restriction has the intended scope.
