The shortcut everyone reaches for
When a WDAC rollout runs into trouble, managed installer is the obvious lever. The team can't get the policy stable, users are complaining, the deadline is slipping. Someone turns on managed installer, points it at the existing deployment tool, and most of the noise goes away.
It looks like a win. It isn't.
Managed installer doesn't decide what should run in your environment. It just shifts the rule to "we trust whatever our deployment pipeline has ever pushed out" — including:
— the tool nobody owns anymore
— the package from a project that ended in 2022
— whatever flows through that pipeline tomorrow
That isn't application control. It's application tolerance.
What the work actually looks like
If application control is the lock on the door, the software lifecycle is the process that decides who gets a key. Without that process, the lock is theatre.
A serious lifecycle has stages no piece of software gets to skip:
— assessment, does the business actually need this, and who owns it?
— security scanning, signatures, vulnerabilities, supply chain
— functional testing, does it work the way the business needs?
— testing under enforced application control on a representative endpoint
That last step is the one most teams skip. It's also the one that matters most. Under enforcement, in a real environment, is where you find out what the software actually does, what its updater fetches, what its plug-ins load, what breaks when a real user touches it.
If it can't run cleanly under enforcement, you have two options. Write a proper policy for it, or reject it. What you must not do is weaken the policy for everything else.
The "this takes too long" objection
The historical answer to a proper lifecycle was that it takes months per application, and the business can't wait. That answer was true ten years ago. It isn't anymore.
The patching problem nobody plans for
Modern applications update themselves. Browsers, collaboration tools, developer tools, security tools — they pull updates straight from the vendor, on their own schedule, outside your deployment pipeline.
The right answer is automation. Close to 100% automated patching, with automated re-testing of every update. Every update. Because sooner or later a vendor will forget to sign something they were supposed to sign, change a certificate, or introduce a new binary their previous releases didn't have. You only find out by testing.
Where WDACManager fits
Most of what made a proper lifecycle expensive was the policy work, figuring out what rules a piece of software needs and keeping them in sync as it evolves.
WDACManager ingests execution telemetry from Microsoft Defender for Endpoint, Windows event logs, or the WDACManager agent, and turns it into deployable policy. Running new software under audit mode and producing the policy that allows it becomes a workflow, not a research project. The same workflow handles updates.
The economics that used to justify shortcuts don't apply anymore.
What to ask your team
- do we have a software lifecycle, and is it applied to every piece of software entering the environment?
- are we testing under enforced application control before production?
- is patching automated, including re-testing every update?
The answers tell you whether you have an application control programme, or a veneer. Managed installer is fine as a tool inside a real programme. It's a poor substitute for one.