Microsoft just shipped the missing primitive for tenant governance: UTCM in Graph (beta)
- Harri Jaakkonen
- 3 hours ago
- 5 min read
“Someone changed a Conditional Access policy at 2am.”
That sentence is boring until it is the first line in an incident report.
Most organizations already have change management, approvals, tickets, and privileged access workflows.
What they rarely have is a reliable, automated answer to one simple question:
What changed in our Microsoft 365 tenant, across all the places that matter, since the last time we checked?
In late January 2026, Microsoft introduced a preview of Unified Tenant Configuration Management (UTCM) APIs in Microsoft Graph (/beta). The promise is straightforward: baseline your tenant configuration, monitor it on a fixed schedule, and detect configuration drift across multiple workloads through one unified API surface.
If you are a CISO, CTO, or a security-minded advisor, the strategic value is not “yet another API.” It is a platform capability that moves tenant governance from hoping nothing changed to knowing exactly what changed—and being able to prove it.
First, the unavoidable reality: it’s Graph beta
Microsoft is explicit: Graph /beta APIs are subject to change and are not supported for production use.
That does not mean “ignore it.” It means:
Treat this as a public preview signal of where tenant governance is heading.
Use it to build operational readiness (process, baseline thinking, monitor design).
Pilot safely in non-production tenants or limited-scope scenarios until v1.0 arrives.
If you make decisions for regulated environments, this matters: you can start shaping your governance model now, without betting your production controls on preview endpoints.
What UTCM is, in plain terms
UTCM gives administrators APIs to control and manage configuration settings across a single workload or multiple workloads in an organization.
Practically, UTCM introduces a lifecycle you can automate:
Snapshot current configuration state (a baseline candidate).
Define that snapshot/baseline as the “desired” configuration.
Create a monitor that re-evaluates the tenant on a schedule.
Review monitoring results and drifts (deviations from desired state).
Remediate using the relevant admin centers or other methods (UTCM is primarily about visibility and detection right now).
Today’s preview supports workloads including Microsoft Defender, Entra, Exchange Online, Intune, Purview, and Teams, with more than 300 resource types referenced via a published schema.
1) Authorization: why this is not “just call Graph”
UTCM has a specific prerequisite: you must add the UTCM service principal to your tenant and grant it permissions before using the tenant configuration APIs.
Microsoft describes two levels of authentication:
Authenticate to Microsoft Graph with a principal that can manage monitors or initiate snapshots.
Configure how monitors run, because when a monitor executes, it impersonates a UTCM-specified principal.
Microsoft also documents an official UTCM service principal (“Unified Tenant Configuration Management”) with a specific application ID (during public preview) and provides steps to create it and assign app roles/permissions.
Why you should care: This is a governance control surface. If your team sets it up casually, you risk creating “yet another powerful identity.” If you set it up deliberately, you get a foundation for drift detection that aligns with least privilege, auditing, and change control.
2) Tenant monitoring APIs: drift detection as a first-class citizen
The tenant monitoring APIs allow admins to:
Create one or more monitors
Review monitoring results
Get information about all active drifts in the tenant
The impact is simple: you can detect deviations from your desired configuration without manually comparing admin centers, scripts, exports, or screenshots.
That is exactly the kind of operational capability that reduces “unknown unknowns” in a cloud tenant, especially when multiple teams administer Entra, Exchange, Intune, Teams, and security/compliance settings.
3) Snapshot APIs: baseline the tenant, declaratively
The snapshot APIs let administrators extract current configuration settings and use that snapshot as the foundation for periodic monitoring.
Microsoft’s framing is important: UTCM aims to provide a declarative representation of tenant configuration—useful not only for drift detection, but also for auditability and troubleshooting.
In other words: you are not just collecting data. You are building an explicit “this is how we intend the tenant to be configured” artifact.
4) Common use cases: what you can do today
Microsoft lists common UTCM use cases mapped to resources.
Get a baseline and create a snapshot job (configurationBaseline)
List and get drifts (configurationDrift)
Create and manage monitors (configurationMonitor)
List and get monitoring results (configurationMonitoringResult)
List/get/delete snapshot jobs (configurationSnapshotJob)
If you want a decision-maker translation:
“Can we prove our tenant matches our security baseline?”
“Can we see what changed, when it changed, and what it deviated from?”
“Can we operate tenant configuration like a controlled system, not a shared whiteboard?”
The parts that determine whether this becomes operationally real
A) Limits that shape your monitoring strategy
UTCM’s preview has clear guardrails:
Up to 30 monitors per tenant
Each monitor runs every six hours (not configurable)
A tenant can monitor up to 800 configuration resources per day across all monitors
Updating a baseline for an existing monitor deletes prior monitoring results and drifts for that monitor
For drifts:
Active drifts remain available for review
Fixed drifts are deleted 30 days after resolution
For snapshots:
Up to 20,000 resources per tenant per month extracted across all snapshots
Only 12 snapshot jobs visible at a time (delete older jobs to create more)
A snapshot is retained for seven days
Why this matters: You are forced to be intentional. You cannot “monitor everything, always” without designing how you spend quota. For many organizations, that is a feature, not a bug, because it makes you define what truly belongs in a baseline.
B) Where this fits if you used Microsoft365DSC
A lot of security and platform teams have relied on community tooling and patterns (notably Microsoft365DSC) to export and compare configuration. The Microsoft365DSC project itself describes UTCM (also referenced as Tenant Configuration Management APIs) as the official, supported direction, noting that in preview the focus is export/snapshot and drift detection, with remediation capabilities expected later.
This is the shift: governance-as-code patterns moving from “best-effort scripting” to “platform capability.”
C) What “good” looks like for a CISO/CTO
The value is not the API. The value is the operating model you can build around it:
A baseline that represents your risk decisions (not a generic benchmark).
Drift detection that feeds incident response and change control.
Audit evidence that is reproducible and less dependent on “who clicked what.”
When UTCM reaches v1.0 maturity, it has the potential to become a core tenant governance primitive: detect drift early, reduce configuration uncertainty, and shorten the time between “something changed” and “we understand the impact.”
Practical examples (the ones that become incidents)
These are the scenarios UTCM is built to catch:
A Conditional Access policy changes outside your process → drift detected.
An Exchange transport rule is modified without approved change → drift detected.
An Intune compliance or security policy is weakened “temporarily” → drift detected.
This is not hypothetical. Tenant configuration drift is one of the most common silent contributors to security regressions in Microsoft 365 environments. UTCM turns that into something measurable.
Bottom line
UTCM in Graph beta is a preview, but it is also a clear signal: Microsoft is building a unified, declarative, multi-workload configuration management layer for Microsoft 365.
If you influence security strategy, now is the moment to:
Identify what belongs in your tenant baseline,
Define how drift should be triaged and owned,
And prepare to adopt UTCM once it reaches production-supported endpoints.
Fortytwo is at the forefront of developing capabilities and services around new functionality in the Microsoft Universe.
Need help or want to learn more? Contact us.
We know that the demand is not for “more settings,” but for governed certainty in a tenant that changes every day.