The on-premises build sheet ended with a single clean proof: plant a honeytoken, sign in against it, watch the alert arrive. The cloud end offers nothing that tidy, because Microsoft publishes no safe way to fire its own cloud detectors on demand. So this build sheet is a different shape. It is not a switch you flip and a light you watch, it is a set of standing checks that together prove the cloud surface is populated, that its telemetry is flowing, and that its risk exchange with the cloud directory is compounding. You run them once to certify the cloud end is live, and you run them again on a cadence, because with nothing to deploy there is nothing whose absence would announce itself. The last check is the closest thing to an end-to-end proof the cloud end allows, so do not stop before it.
Confirm the inventory is populated
The first evidence that the cloud end is alive is that it knows about your cloud identities at all. Open the identity inventory and look at the environment each identity is tagged with, because that column is doing the work a connector status would do if a connector existed.
| Check | What good looks like | Why it proves the cloud end |
|---|---|---|
| Human identities inventory | Rows tagged Cloud only and Hybrid appear alongside the on-premises rows | If Entra ID is your directory, cloud-only and synced identities are enumerated automatically. Their presence is the population signal; their absence is the fault. |
| Accounts tab on an identity | A single identity shows its linked Active Directory, Entra ID, and third-party accounts together | Generally available since early 2026. Confirms the fabric is correlating the same person across directories, not just listing them separately. |
| Non-human identities tab | Service principals are listed, with the used-by-AI-agents insight where it applies | Preview. Confirms workload-identity visibility is on. Treat as a capability to watch, not yet a control to depend on. |
Confirm the telemetry is flowing
Presence in the inventory says the identities are known. It does not say their activity is arriving. Advanced hunting is where you confirm the cloud telemetry is actually landing, and two tables answer two different questions that are easy to conflate. Run these and read them as separate proofs.
// 1) Cloud identities are known to the identity fabric
IdentityInfo
| where SourceProviders has "EntraID"
| summarize arg_max(Timestamp, *) by AccountObjectId
| where IdentityEnvironment in ("CloudOnly", "Hybrid")
| project AccountDisplayName, AccountUpn, SourceProviders, IdentityEnvironment, RiskLevel
| take 50
// 2) Cloud sign-in telemetry is arriving (Defender for Cloud Apps sourced)
IdentityLogonEvents
| where Timestamp > ago(7d)
| where isnotempty(AccountObjectId)
| summarize LogonCount = count() by Application, ActionType
| order by LogonCount descA non-empty result on the first query, with identities marked cloud only or hybrid, is your proof that the cloud side is populated at the data layer and not just in the portal view. A non-empty result on the second is a separate and sharper proof: those cloud sign-in rows are captured by Defender for Cloud Apps, not by a sensor, so their presence confirms the cloud-authentication pipeline specifically. Do not read the two as one. And do not be alarmed by an empty result from the on-premises directory-events table when you filter it for cloud rows, because that table holds domain-controller events by design and carries no cloud rows at all; the same is true of the third-party identity-events table, which stays empty until you connect an Okta or similar provider and is a preview surface besides.
Confirm coverage is scored
Because there is no connector object to point at, the coverage score is the closest thing to a connected indicator the cloud end ships. Two surfaces carry it, both in preview and both rolling out gradually, so one or the other may not yet be present in your tenant.
| Surface | What to confirm | Prerequisite |
|---|---|---|
| Coverage and maturity report | The Entra identity-provider card shows a non-zero coverage score with no basic-connectivity actions outstanding | A Defender for Cloud Apps or Defender for Identity license, plus Security Reader. Preview. |
| Identity Security dashboard | The identity-providers summary shows human, non-human, and agentic counts with a coverage gauge that is populated and trending | A Defender for Identity license and an Entra ID Protection license. Preview. |
Confirm the queue is producing
Population and telemetry prove the surface is alive. The queue proves it is doing its job. In the unified incident queue, filter by detection source and separate the identity products from one another, because the queue lets you distinguish an alert that came from this product from one that came from Entra ID Protection. Filter to Defender for Identity and, separately, to Entra ID Protection, and confirm that both are producing alerts over a trailing month rather than only the on-premises product. Two live sources, not one, is the evidence that the cloud detection surface is not merely present but actively firing, which is the thing you cannot force with a test.
Confirm the risk exchange, the closest thing to a proof
This is the one place the cloud end lets you run something close to the honeytoken test, and it is worth doing deliberately because it exercises the whole cross-product loop. Entra ID Protection documents safe ways to raise a benign risk on a disposable account, the cleanest being a sign-in from an anonymous network such as Tor, or a sign-in with unfamiliar properties against a test account that has some sign-in history. Trigger one of those against a throwaway identity, confirm it appears in the Entra risky sign-ins view, then follow it across.
| Step | Where | What confirms it |
|---|---|---|
| Raise a benign risk | Entra ID Protection, against a disposable test account | The event lands in the risky sign-ins report within minutes. |
| Watch the compounding | Entra ID Protection, Risky users, the user timeline | The account progresses from Medium to High under a detection typed as Unified risk signals. |
| Cross into the fabric | The Defender identity page, the Risk score tab for that identity | The zero to one hundred identity risk score and its contributing signals populate, tying the cloud risk back to the identity narrative. |
That chain is the cloud-end equivalent of the honeytoken proof. It does not fire one of this product’s own cloud detectors, which nothing safely can, but it proves the pipeline that matters most: that a cloud risk compounds, crosses into the identity fabric, and is available to the conditional access you already run. If the exchange does not compound, that is your signal to go back and confirm the unified-risk-signals setting is actually enabled, the ambiguity the concept article flagged, rather than assuming it was on.
Report it on a cadence
Because the cloud end is verified by standing indicators rather than a one-time test, reporting on it means reading those indicators on a schedule rather than filing a pass. The durable surfaces are Secure Score, where the identity recommendations refresh daily and give you the working list, and the identity initiative inside Exposure Management, which scores the trend over time; note honestly in any report that Microsoft’s own pages disagree on whether that initiative is still labelled preview, so cite it as a live surface with an unsettled label rather than a settled score. Put the whole cloud end on the same quarterly rhythm you should already run for the on-premises estate, where you re-run the readiness check, confirm every sensor is healthy and current, and re-read the cumulative-update floor because it moves. For the cloud end, the quarterly pass is lighter but no less necessary: re-confirm the inventory still tags cloud identities, that the hunting queries still return, that the coverage score has not regressed, that both detection sources are still producing, and that the risk exchange still compounds. Nothing here fails loudly, which is exactly why it belongs on a calendar.
The short version to run down when you certify the cloud end and each quarter after:
- The inventory shows cloud-only and hybrid identities, with the non-human tab populated where you use it.
- The two hunting queries return, proving the identities are known and the cloud sign-in telemetry is arriving.
- The coverage-and-maturity or dashboard score is non-zero and trending, with no basic-connectivity actions outstanding.
- The incident queue is producing from both Defender for Identity and Entra ID Protection, not on-premises alone.
- A benign risk raised in Entra ID Protection compounds through unified risk signals and lands on the identity page Risk score tab.
- Secure Score and the Exposure Management identity initiative are scoring live tenant data and are reviewed on the quarterly pass.
The honest limit of this proof
State plainly, to yourself and to anyone you report to, what this build sheet certifies and what it cannot. It certifies that the cloud pipeline is populated, flowing, correlating, and compounding risk into the cloud directory. It does not certify that every one of this product’s cloud detectors, the consent-abuse and session-theft and sync-account detections, has been fired and observed the way the honeytoken lets you certify the on-premises side, because Microsoft ships no safe way to trigger them. That is not a gap in your deployment, it is a limit of the platform, and the defensible position is to say so rather than to imply a completeness the tooling does not allow.
Where this sits
With this, both ends of the fabric are not only designed but proven. The sensor estate stands up the on-premises end and proves it with a honeytoken; the cloud end lights up on licensing and is proven by these standing checks. The two-ended shape the anchor promised is now complete: instrumented where you must build it, confirmed where you cannot, and reported on a cadence that treats the quiet half with the same seriousness as the loud one.
Defender XDR
‹ Previous: [D 3.4] The Cloud End: What Lights Up Without a Sensor
Next: [D 4] Defender for Office 365: What Email Security Became ›
