Skip to main content

Back to all products

AppControl Cloud

Plan, measure and roll out App Control for Business (WDAC) with no agent and no third-party backend.

In developmentSecure IT
Talk about this product

A straight answer on where it stands, with no waiting-list theatre.

Who it is built for

Windows endpoint and security teams that have to introduce application control and want to know what it breaks before it breaks.

The problem

App Control is rated one of the hardest Windows security features to deploy. Rule semantics are opaque, the blast radius of a policy is hard to estimate, and a failed attempt takes workstations down. That is why the feature stays unused in many environments, even though security audits keep asking for it.

Our approach

Analyse first, enforce second. The complete analysis chain - fetch the data, understand the rules, measure coverage and blast radius, generate and export the policy - runs in the browser against your own tenant. There is no backend of ours that could see your data.

Where the data goes

The analysis runs in your browser, against your own tenant. There is no server of ours in the path.

YOUR TENANT, YOUR BROWSERDefender for EndpointApp Control telemetryyou already collectREADAppControl Cloudruns entirely in thebrowser tabDEPLOYMicrosoft IntuneApp Control policiesin your own tenantNo connection. None to draw.Opsorareceives no data
The crossed line is the point of the drawing. There is no connection to draw, because the product has no server of ours behind it.

This is architecture, not a promise

There is no backend of ours to trust, because there is no backend of ours. The application is a static page: it talks to your tenant from your browser using your sign-in, and the telemetry, the analysis and the generated policy never leave that tab. It is not a setting that can be switched, and not something that could be sold as an upgrade.

Analyse first, enforce second

The order matters. A measurement of what a policy would do comes back before a policy does.

Endpoint adminworks in thebrowser, signed into your tenant.AppControl CloudNO AGENT, NO BACKEND OF OURS01Fetch thetelemetry02Measure coverageand blast radius03Generate thepolicy04Deploy orexportYour Microsoft365 tenantDefender for Endpointand Intune, reached withyour own sign-in.STARTYOURTENANTWhat the policy would do, while it is still a draftThe policy, in audit mode until you enforce it
The position numbers key to the parts list below. Step 02 returns to you before step 04 does, which is the whole argument: you see what a policy would do while it is still a draft.

Parts list

  • 01Fetch the telemetryEffect: App Control events your endpoints already produce are read from Defender for Endpoint. Nothing new is installed and no agent is deployed to collect them.
  • 02Measure coverage and blast radiusEffect: The draft is run against the events you actually have, so the effect is measured rather than estimated. Every decision traces back to the rule that caused it.
  • 03Generate the policyEffect: Base and supplemental policy XML is produced in the browser, with a lint pass for the mistakes that make a machine fail to boot.
  • 04Deploy or exportEffect: Export the XML and take it elsewhere, or deploy to Intune from here. Deployments start in audit mode, keep a rollback snapshot, and show a change preview before anything is written.

What a policy would block, before it blocks anything

A rule set is easy to write and hard to predict. This is the part that decides whether the project ships.

Observed eventsfrom your own tenant,not a sample setDraft policynot deployed,not enforced,nothing at riskWould still runCovered by a rule, and the drawing can namewhich rule and at which level.Would be blockedNo rule matches. This is the list that turnsinto work, or into a decision not to enforce.None of this is enforced. Enforcement stays a separate, deliberate step.
No counts are shown here because they would be invented. The figures come from your own events, in your own tenant, when you run it.

The reason App Control projects stall

App Control is rated one of the hardest Windows security features to deploy, and the reason is rarely the rule syntax. It is that nobody can say what a policy will break until it breaks something. Measuring the effect against real events, while the policy is still a draft, turns that from a risk into a list.

What it does

  • 01Analysis of existing event data from Microsoft Defender for Endpoint
  • 02Rule explorer with explainable semantics instead of guessing at XML
  • 03Measure coverage and blast radius before a policy goes enforcing
  • 04Generate and export policies, and manage them in Microsoft Intune
  • 05A change preview before deployment, and rollback snapshots for the way back
  • 06Drift detection: what changed in the tenant since the last known state
  • 07Change-board evidence, produced from the generated rule set itself
Technical scopeWindowsApp Control for BusinessMicrosoft IntuneDefender for Endpoint

Editions and terms are not settled yet

The product is in development. Editions, scope and terms will be set together with the first users. If you want to run it, talk to us before that is fixed.

Register as an early user