An application that updates itself, and three ways out

Application control is a statement about which code may run. An application that updates itself is a statement that the code will change without asking. Those two facts meet in every estate, and there are only three ways the meeting can go.

Two of them cost you something. The third is the one worth building around.

Block the update #

The policy holds. The new binary is not the one you approved, so it does not run. This is application control working exactly as designed, and it is the honest answer.

What it costs you is people who cannot work, and a queue behind them.

That queue matters more than the outage. Under pressure, the fastest way to clear it is a broad exception with no expiry, so refusing the update frequently ends up widening the policy anyway. It just takes longer and arrives with less thought attached.

Trust the application's own updater #

Designate that updater a managed installer, and everything it writes is trusted from then on. The problem goes away immediately.

What it costs you is the policy.

Not visibly, and not at once. The difficulty with this answer is that it works, which is precisely why it gets used again for the next application that will not sit still. Each designation is defensible on its own and the set of them is not. After several, the policy permits more than anyone can enumerate, and no individual rule looks wrong.

There is a principle underneath this worth stating plainly. An application should not earn trust for the fact that it updates itself. That is a property of its release engineering, not evidence about its behaviour, and treating it as a qualification inverts what the control is for.

There is a second problem with this option, separate from how many times you use it. Designating an installer trusts everything it and its child processes write, which makes a badly chosen updater a route to trusted execution rather than just a wider policy. Managed installer is a trust channel covers what to ask before designating anything.

One vetted deployment path is sound. Nine is a policy nobody can read.

Route it through a path you already vetted #

Packaged and delivered by the deployment mechanism your policy already trusts, on a schedule you set.

What it costs you is nothing new, and that is the whole argument. The trust already exists and has already been reviewed, so software arriving this way inherits a decision somebody made deliberately. No new rule is written. The trusted set does not grow.

The application stays current and the policy stays the shape you approved. Those are usually presented as a trade, and this is the case where they are not.

Why the middle one is the default #

Nobody chooses to accumulate managed installers. It happens because the first designation solves a real problem on a real deadline, and the second one is easier than the first.

Which is why the useful test is not whether any single designation was justified. It is whether somebody can name all of them and say who approved each. One or two can be defended in an audit. The estates that struggle are not the ones that made a bad decision, they are the ones that made the same reasonable decision nine times.

The application control lifecycle covers why that list needs an approval gate in front of it, and base and supplemental policies covers where those rules can and cannot live.

What PoliEze does about it #

PoliEze keeps every acting installer in one visible list with an approval in front of anything joining it, so the trusted set is something you decide rather than something you discover. PoliEze Flow takes the third option further, delivering each new release through the path you already trust so the application stays current without the policy widening to accommodate it.