Device lockdown
Keep Windows machines on a policy IT sets, so a user cannot install software nobody approved. Machines enrol over the internet with a site key, a signed policy is applied and kept offline, and a user who needs something asks for it in a window on their own desktop.
What a machine on the policy cannot do
Each protection is a setting you put in one of three states: off, report (read the machine and say what it would change, changing nothing) or enforce. Every machine reports each setting back in words — compliant, changed, not compliant, not applicable, paused or the error — so a setting that could not be applied is never shown as quiet.
- Local administrators. Only the accounts you name stay in the Administrators group. The built-in Administrator is always kept, and enforcing with nobody named is refused, so a machine cannot be left with no administrator at all.
- Windows Installer. No one runs an
.msiIT has not deployed, and the setting that lets a user’s install run with administrator rights (AlwaysInstallElevated) is switched off. - Programs on USB drives. Nothing runs from a removable drive; files can still be opened and copied.
- Microsoft Defender hardening. Seven attack surface reduction rules, potentially unwanted apps blocked and SmartScreen set to block, with an audit mode of its own. Where Defender is passive beside another antivirus, or cannot be asked, the setting reads not applicable — never “no protection”.
- Application control. Only Windows, Microsoft and the software you approve run. Enforced through App Control for Business (WDAC): put it in audit first, review what it would have blocked across the machines, and approve each one into the policy by publisher or by file hash.
- Administrators too, by default. Where every user is a local administrator, a block that skipped administrators would do nothing, so the installer and application-control blocks reach them unless you turn that off. These stop accidental and casual installs; against a determined administrator, the answer is removing local administrator rights, which is the first setting.

Enrolling a machine: one installer, no password
You make a site key on the Devices page and download the installer that carries it. Run Install.cmd on a machine, or hand it to Group Policy or your RMM tool; it needs nothing typed. The key can be limited to a number of machines or a number of hours, and revoked: revoking it stops new enrolments, and the machines already enrolled stay.
- A separate component. Lockdown runs as a SYSTEM scheduled task on enrolled machines only. Vantage’s monitoring agent on your servers is unchanged and still runs as a least-privilege service account.
- Each machine holds its own key, made in the machine’s key store and never exported, and signs every call it makes. The dashboard keeps only the public half and refuses a call whose clock is far off or that it has seen before.
- Nothing is opened inbound. Machines reach your Vantage server through the cloud management connection (the remote console switched on in Settings), so a laptop at home is managed the same as one in the office. A private trial does not open that connection, so a trial cannot enrol machines.
- It keeps itself current. A newer device script is offered signed, checked against its signature and hash before it touches the disk, and put back to the previous copy if it keeps failing to finish a run. Running a freshly downloaded installer again upgrades a machine in place.

A signed policy that holds when the machine is offline
The policy is signed on your Vantage server with a key that never leaves it. A machine checks the signature before it applies a policy, keeps the copy, and checks it again before applying that cached copy when it cannot reach the dashboard — so a laptop on a plane stays locked down. Between its 15-minute check-ins each machine holds a connection open, and a policy change, an approved install or a pause reaches it in seconds.
When someone needs to install something legitimate
Lockdown is only workable if there is a sanctioned way through. There are three, and each is bounded and logged.
- Allow installs for a few hours. An administrator allows installs on one machine for up to 24 hours. The grant is signed and names that machine; it lifts the installer and USB blocks for the window and puts them back on its own. Defender and the administrators list stay as they are.
- A request from the user’s own desktop. A tray icon and a Start-menu entry open a small status window: each protection in plain words, whether installs are allowed right now, and the user’s recent requests. The user asks for what they need and why — a reason can be required — and an operator or administrator approves or denies it on the Devices page. An online machine opens its install window at once.
- An authorization code read over the phone. A machine with no connection shows a Request ID; the user reads it out, and the Devices page turns it into an eight-character code (
XXXX-XXXX) the machine checks itself, with nothing to contact and no clock to agree on. A code is good for that request only, within 24 hours. - A blocked program asks why. When application control blocks a program, the user is prompted for a reason and can ask IT; every justification is logged on the Devices page with who, what, why and the outcome. Under WDAC the block cannot be lifted on the machine, so the request goes to IT, whose approval goes into the policy.
- Pause protection. A machine can be taken off enforcement for a bounded window — online from the page, or with an offline code by phone — and it comes back on by itself. The machine keeps reporting while paused.
It does not lock itself, or the machine, out
Application control is the setting that can brick a machine, and the component is built so that it cannot do that to itself.
- WDAC enforce is applied only when the device script itself is trusted. Vantage manages its own code-signing certificate, the installer trusts its root on the machine, the script is signed with it, and the policy always trusts that signer. A machine where the signature is not valid and trusted keeps the policy in audit and says why, rather than enforcing and dropping its own script into PowerShell’s Constrained Language Mode.
- A guard runs before anything else. If the script finds itself locked down by a policy it applied, it removes that policy and says so.
- The SRP engine does not enforce the allow-list. An enforced Software Restriction Policy puts the whole machine’s PowerShell into Constrained Language Mode, so Vantage refuses it and points at WDAC. SRP still carries the other protections.
- Switching the engine stands the old policy down instead of leaving it enforcing behind your back.
What it does not do
- No AppLocker. Application control is WDAC; an AppLocker allow-list (Enterprise editions) is not built.
- No folder rules under WDAC on Server 2019. WDAC allows by publisher or file hash there; a program is allowed by approving it from the audit review, not by naming its folder.
- Signed WDAC policies need a boot-trusted certificate. On a Secure Boot machine a self-signed signed policy is rejected at boot, so policies are unsigned by default; a signed mode is there for estates whose certificate is in the firmware’s trust.
- No Windows sign-in control yet. Signing in to enrolled machines with Vantage accounts is not built.
- Not a substitute for removing administrator rights. The installer and SRP blocks are machine settings a knowledgeable administrator could switch off; WDAC is the engine that holds against one.