Enterprise

Bring security, IT and application owners into one operating model

PoliEze gives each team a clear role in reviewing software, approving trust, managing policy change and moving safely to enforcement.

The operating model

Clear ownership at every stage

  • Security

    Defines and approves what may run.

  • IT operations

    Deploys policy and manages the Windows estate.

  • Application owners

    Provide requirements and request software trust.

  • Service desk

    Restores user access through the approved process.

  • Change management

    Controls when policy changes move into production.

  • Executive

    Owns the risk and sees whether the control is working.

What changes for each team

Application Intelligence

Turn millions of events into a shortlist you can approve

Grouping software activity by file, signer and publisher is what reduces a fleet of events to a set of decisions a person can actually review.

From fleet scale noise to policy decisions A funnel narrowing from left to right in four stages. Thousands of endpoints across multiple business units and personas generate millions of code integrity events. Grouping those by file, signer and publisher reduces them to hundreds of distinct applications, and what reaches a person is a shortlist of policy decisions small enough to review and approve. FROM NOISE TO DECISIONSPoliEze Application IntelligenceRulesdrafted for approval YOUR WINDOWS FLEET Thousands of endpoints across multiple business units and personas WHAT THEY GENERATE Millions of code integrity events audit and block, arriving continuously GROUPED BY SIGNER Hundreds of distinct applications one broken application is one row, not four hundred DRAFTED AS POLICY Rules ready for review at the level that survives the next update

  1. YOUR WINDOWS FLEET

    Thousands

    of endpoints

  2. WHAT THEY GENERATE

    Millions

    of code integrity events

  3. GROUPED BY SIGNER

    Hundreds

    of distinct applications

  4. DRAFTED AS POLICY

    Rules

    ready for review

What is arriving

  • Signed
  • Unsigned
  • Publisher
  • File metadata
  • TBS hash
  • File hash
  • Would block (3076)
  • Blocked (3077)

Application Intelligence accelerates rule creation, while approval remains with your authorised team.

What changes when the fleet gets big, and the twelve difficulties behind it

Scoped by design

Persona driven policy management

One policy estate, with a profile for each group that needs different software. What is delegated is scope, not authority.

  • Corporate

    Knowledge workers, the default

    The largest group, so it carries the tightest workable policy.

  • Engineering

    Developers and platform teams

    Needs the build and debug tooling that is denied everywhere else.

  • Finance

    Finance and treasury

    Macros are a requirement here, so they are governed by signer rather than allowed loosely.

  • Frontline

    Field, retail and kiosk devices

    The smallest allowlist on the fleet, and usually the easiest to enforce first.

  • IT administration

    Endpoint, server and support teams

    The highest privilege group, so it gets the most scrutiny rather than the most latitude.

How the profiles are structured, and where the deny set has to live

Worked examples

See how common application control challenges are handled

Explore six practical scenarios covering the questions teams face most often.

Version floor and ceilingI want everyone on the current Chrome, and old builds to stop running.

How it is expressed

Two rules, not one. An allow rule at the file publisher level with a minimum version, so Google's signature at that version or newer runs. Then a deny rule in the base with a maximum version, because that is what actually stops the old build. An allow rule only stops an older build matching that rule, and a build your deployment tool installed is still authorised by its managed installer origin. A deny beats that.

What catches people out

Both numbers depend on the version metadata in the signed file being correct, and someone has to move them when the fleet moves. Raise the floor faster than your deployment rings and you stop people working mid update.

What PoliEze does

PoliEze shows who is on which build before you move the floor, and moves it ring by ring, so the number never gets ahead of the fleet it is meant to describe.

Signer denyThere is a vendor we no longer want executing anything, anywhere, on supply chain grounds.

How it is expressed

A deny rule at the signer level, in the base policy. It has to be the base, both because a deny placed in a supplemental is ignored and because a deny in the base beats an allow anywhere else. That is what stops a business unit quietly re-allowing it later.

What catches people out

Check what else that certificate signs before you deny it. Vendors sign more than one product, and a broad certificate deny can take out something you still depend on.

What PoliEze does

PoliEze shows everything that certificate signs across your estate before the deny is applied, so the blast radius is something you saw rather than something you discovered.

Unsigned softwareOur most critical application is unsigned and the vendor will not sign it.

How it is expressed

A hash rule for the exact binaries, or a path rule with the directory write protected. Both are weaker than a signature, and both are a standing commitment rather than a one off.

What catches people out

A hash rule breaks on every update, so someone has to own reissuing it. Signing it yourself internally is the better long term answer, and asking the vendor at renewal is the best one.

What PoliEze does

PoliEze owns the reissue when the binary changes, so an unsigned application is a standing decision with a review date rather than a standing manual commitment.

PerformanceOur fleet is low spec. What does this cost us in performance and launch latency?

How it is expressed

Very little, because of where the enforcement sits. Code Integrity is part of the Windows kernel and is already running whether or not you have a policy. A policy gives it something to evaluate against, it does not add a process. Policies load at boot, so there is no agent being consulted on every launch to ask whether something may run. Our agent orchestrates policy and reports drift and tampering, and it is not in the execution path.

What catches people out

It is not literally free, and how you build the policy is what decides the cost. Code Integrity still evaluates each file against the rules, so a policy carrying thousands of hash rules is more work than one built on signer and publisher rules. That is another reason the rule level is the decision it is.

What PoliEze does

PoliEze keeps the policy at the rule level that stays cheap to evaluate, and shows which rules are no longer used, so the cost does not creep up as the estate accumulates exceptions.

Certificate rotationA vendor rotated their signing certificate and their application stopped running.

How it is expressed

The old rule no longer matches, so the file is refused. It needs a new rule for the new signer, going through review as a trust decision rather than being waved through to get people working.

What catches people out

This is the moment to confirm the new certificate really is theirs. A publisher change is also what a supply chain compromise looks like, and the pressure to just approve it is highest exactly then.

What PoliEze does

PoliEze raises the rotation as a decision with the old and the new signer side by side, so somebody approves the change deliberately instead of under pressure to get people working.

Developer toolingOur developers need Visual Studio and Docker and both keep getting blocked.

How it is expressed

Development tools are the hard case, because they generate and run binaries at runtime and often update themselves. Microsoft is direct that an application which self-updates loses its managed installer origin information and may stop running, and that installers which extract or generate binaries and run them immediately may not be covered by the heuristic either. The workable answer is a base policy variant for that device group, signer rules for the toolchain, and the build output directory decided deliberately rather than by accident.

What catches people out

This is the group most likely to be handed a broad path rule to make the problem go away, which trusts anything written to that directory. If those users are local administrators too, the path is writable by the person the policy is meant to constrain.

What PoliEze does

PoliEze gives this group its own profile with the scrutiny that comes with it, so the answer to a blocked build is a scoped rule rather than a broad path rule nobody revisits.

Getting started with PoliEze for App Control

From discovery to governed enforcement.

The first ninety days Four phases flowing left to right, each pointing into the next, and three of them repeating rather than completing once. Days one to thirty are discovery and audit mode, looping through reading events, adding rules and reading again. Days thirty one to sixty move enforcement out ring by ring, looping to tune the policy and capture the deltas, with each ring gated on the one before it going quiet. Days sixty one to ninety reach full enforcement across the fleet, which is the one milestone rather than a loop. Beyond day ninety the estate is maintained, a loop that does not end because the rules follow application change. THE FIRST NINETY DAYS DAYS 1 TO 30 Discover and audit Inventory taken, policy in audit, signals arriving read, add rules, read again DAYS 31 TO 60 Enforce by ring Ring by ring, each gated on the last going quiet tune, capture the deltas DAYS 61 TO 90 Fully enforced The whole fleet, and staying that way BEYOND 90 Maintain It does not end on app change Day 0 Day 30 Day 60 Day 90

  1. DAYS 1 TO 30

    Discover and audit

    Inventory what the fleet actually runs, deploy the policy in audit, and read what would have been blocked.

  2. DAYS 31 TO 60

    Enforce by ring

    Enforcement moves out one ring at a time, each one gated on the ring before it going quiet.

  3. DAYS 61 TO 90

    Fully enforced

    The rest of the fleet, on the same gate. Enforced, not enforced in principle.

  4. BEYOND 90

    Maintain

    Applications keep changing, so the rules keep changing with them. This part does not end.

What decides whether it is ninety days

Whether we can see the signals

Audit only progresses while endpoints are running and reporting. A policy narrowed on partial evidence is the one that breaks a department later.

The size and shape of the estate

More business units, personas and unsigned software all use more of the ninety days. A tightly managed fleet moves through it faster.

PoliEze can create, deploy and update policies in minutes. The ninety days allows time to collect sufficient evidence, validate decisions and move enforcement through the organisation's change process. Read how a rollout is staged.

Working with us

Choose the platform, or the platform with expert support

Use PoliEze with your own team, or work with the engineers who have implemented and operated Windows App Control at enterprise scale.

You run it

Your platform team owns the estate and uses PoliEze to author, approve, stage and reverse. We onboard you and stay available.

For teams with application control experience in house.

We run it with you

Work alongside engineers who have implemented and operated Windows App Control across nearly 500,000 endpoints.

We support discovery, policy design, audit analysis and enforcement, then hand over a governed environment your team can operate with confidence.

For teams doing this the first time, working to a deadline, or stuck in audit mode long enough to want help.

Questions

What large teams ask

Not the question you had?

The guides go deeper: event IDs and what they mean, why an Intune deployed app gets blocked, and what audit mode does not tell you.

Read the guides
How does this work with Configuration Manager rather than Intune?
Both are supported as delivery mechanisms. Configuration Manager can also act as a managed installer, which changes what needs to be in the policy, so the setup differs slightly. We work through which model fits during onboarding.
What about devices that are not managed?
Application control only protects devices the policy reaches. Unmanaged devices are out of scope by definition, and it is better to name that gap explicitly than to imply coverage that is not there. Discovery will usually surface how large the gap is.
Our standards and control mappings still say WDAC. Does the rename affect them?
No. WDAC and App Control for Business are two names for the same feature, and the policy format did not change with the rename, so existing standards, control mappings and audit evidence remain valid. Only the branding moved, and reports can carry whichever name your framework documentation uses.
Is there a limit on fleet size?
The practical constraints tend to be organisational rather than technical. Policy authoring and approval are where large organisations slow down, which is why those parts are the focus rather than raw device count.

Talk through your policy estate

Bring the shape of your environment, how many business units are involved, and what your current policy looks like. We will be straight with you about what is hard and what is not.

Book a demoSee the platform