Azure Arc gives Microsoft a live inventory of servers across your estate, including machines you never intended to surface. When that telemetry shows a server Microsoft cannot tie to an entitlement, it becomes a signal that raises your audit risk.
Azure Arc was built to help you manage servers wherever they run, on premises, in other clouds, at the edge, from a single Azure control plane. That is a real operational benefit, and it is also the point of tension. The same connection that lets you manage a server lets Microsoft see it. In 2026, with Microsoft applying anomaly detection to licensing and telemetry to choose audit targets, an Arc connected server that does not map cleanly to an entitlement is exactly the kind of signal that draws attention. This article explains how that happens and what you can do before it does. For the wider set of signals, see our pillar on Microsoft audit triggers.
What Arc actually reports
When a server is onboarded to Azure Arc, it appears in Azure as a managed resource and reports metadata about itself: operating system, configuration, installed software in many cases, and its ongoing presence. This is the value of Arc for operations teams. It is also a continuous, authoritative record held by Microsoft of a machine that may sit entirely outside Azure. The server does not have to be running in Azure to be visible. It only has to be connected.
How telemetry becomes a trigger
Microsoft holds entitlement data on one side and telemetry on the other. When the two are compared, the gaps stand out. A server visible through Arc that carries a licensable workload, with no matching entitlement on record, is a mismatch. One mismatch is noise. A pattern of them, or a sudden rise in visible servers, is a signal. The 2026 selection model is built to find exactly these patterns, and an estate that has connected servers to Arc without first reconciling its licensing has effectively handed Microsoft the map.
The common scenarios are predictable.
- Legacy servers connected to Arc for management that were never included in any license count
- Workloads running on the wrong edition, visible in the configuration data Arc reports
- Servers in other clouds surfaced through Arc that the licensing team did not know were in scope
- A jump in Arc connected machines after a consolidation project, with entitlements that lag behind
A simple mismatch, illustrated
The shape of the problem is easiest to see laid out. The figures below are indicative and meant only to show the gap, not any specific case.
| Source | What it shows |
|---|---|
| Arc inventory | 180 servers visible, with operating system and workload data |
| Entitlement records | 150 servers covered by current licenses |
| Apparent gap | 30 servers with no clear matching entitlement |
| After reconciliation | many resolved as covered, decommissioned, or non production |
Indicative only. A visible gap is not the same as a real shortfall, which is precisely why the reconciliation matters.
The gap on first sight looks like exposure. After reconciliation, much of it usually resolves: servers already entitled under a broader agreement, machines decommissioned but still connected, instances that carry development or disaster recovery rights. The danger is letting Microsoft do that reconciliation first, on its terms, rather than doing it yourself.
What to do before the signal forms
The defense is not to avoid Arc. It is to reconcile before you connect, and to keep reconciling as the estate changes. The steps are straightforward.
- Inventory the servers you intend to connect and map each to an entitlement before onboarding
- Resolve the obvious mismatches first: retire decommissioned records, correct edition errors, confirm coverage
- Document the rights that apply to non production instances so they are not read as gaps
- Treat any rise in Arc connected machines as a prompt to recount, not a routine operational change
This is the same discipline that reduces audit risk across the board, covered in reducing your Microsoft audit profile. Arc simply makes it urgent, because the telemetry is continuous and the visibility is already Microsoft's.
Where Arc fits the wider risk picture
Arc is one input among several that the 2026 selection model weighs, alongside Microsoft 365 and Azure consumption signals. In a hybrid estate, where servers span on premises and multiple clouds, the inputs compound and the picture gets harder to read from any single source. Mapping that whole picture is the subject of the audit risk map for a hybrid estate. The lesson Arc teaches in isolation holds across all of them: the data Microsoft can see is data you should reconcile first.
The next step
Azure Arc gives Microsoft a live, authoritative view of servers it might otherwise never count. That visibility becomes audit risk only when your entitlements do not keep pace with what Arc reveals, and the fix is to reconcile on your own terms before the mismatch becomes a signal. The full set of signals and how to manage each sits in our pillar on Microsoft audit triggers. Download the guide below for the reconciliation checklist and the telemetry signals that matter most.
When the exposure is real, our ELP exposure modeling team stress tests every line the auditor will count.
Reconcile what Arc reveals before Microsoft does.
Get the audit triggers guide with the telemetry signals that raise risk and the reconciliation checklist that closes the gap.
Download guide