The anchor promised two ends, and the rest of the pillar spent its time on the one you build. This article is about the one you mostly do not. The on-premises fabric is an estate you stand up server by server, but the cloud end of Defender for Identity lights up on licensing, with no workspace to create, no Entra connection to make, and no switch to find. That sounds like less work, and it is, but it hides a harder question than deployment ever posed. If there is nothing to install, how do you know the thing is watching, and how do you prove it to anyone who asks. The discipline of the cloud end is not standing it up. It is knowing exactly what is automatic, what you still connect by hand, and how you confirm a surface you never had to build.
What lights up on its own
Start with what asks nothing of you, because it is more than people expect. The product itself is provisioned automatically now. The instance that older guidance told you to create no longer has a setup screen; Microsoft’s own wording is that onboarding is automatic for new customers with no need to configure a workspace, and the only exception left is a tenant moving into the government clouds, which still creates its instance by hand. Once the tenant carries the license, the cloud-native detections are simply present. The whole wave of Entra identity detections that shipped through 2026, the adversary-in-the-middle consent abuse, the stolen session cookie replayed against the cloud, conditional access bypassed through a non-compliant device, a guest promoted to member, an account created and handed Global Administrator in one motion, all of it fires with no sensor anywhere near it and no connection for you to establish.
There used to be a step here, and it is worth naming so nobody goes looking for it. For years you turned the cloud integration on from inside Defender for Cloud Apps, a checkbox that enabled the data flow and took up to half a day to settle. That page is gone. It now redirects to the same documentation that tells you onboarding is automatic, because when the products collapsed into the unified portal the toggle stopped being a thing you operate and became something the platform simply does. If a runbook still tells you to enable Defender for Identity data integration in the cloud-apps settings, that runbook is describing a control that no longer exists.
One honesty is owed here, because it shapes everything that follows. Microsoft documents no step to enable the Entra detections, which is not quite the same as Microsoft documenting that they are automatic. The absence of a switch is the whole evidence, and it is good evidence, but the right posture is to treat the cloud surface as on and then to verify that it is, rather than to assume silence means coverage. That single move, from assuming to confirming, is the reason the cloud end needs its own build sheet at all, and it is where this article is headed.
What you still connect by hand
Automatic covers Microsoft’s own directory. It does not cover the identity providers you run alongside it, and those are the one part of the cloud end that is genuinely a deployment task. If you carry Okta, CyberArk Identity, or SailPoint, you connect each one through the data-connector catalog in the portal, standing up a service account and an API token on the provider side so that its inventory, its posture findings, and, for Okta, its detections flow into the same identity picture as everything else. All three of these connectors are still in preview, and Okta’s own documentation is inconsistent about whether it has graduated, so treat the whole third-party surface as preview and plan for it to move. OneLogin is the exception that will trip a careful reader: its coverage is real and its alerts land in the same queue, but you connect it through Defender for Cloud Apps rather than here, so an administrator hunting for a OneLogin connector in the identity settings will not find one. And if you already run Okta through Defender for Cloud Apps and then connect it here as well, you will see the same Okta activity twice; pick one path and stay on it.
PingOne deserves a flag rather than a paragraph. Microsoft lists it among the providers that get identity recommendations, but publishes no connector page and no setup path for it, which leaves it in an odd state where coverage is claimed and the mechanism to obtain it is undocumented. I would not plan a PingOne rollout on the strength of that listing until Microsoft says how you connect it. The Entra Connect sensor is the other piece of the cloud story that is really an on-premises install, because the machine that watches the synchronization seam sits on your side of the wire; it belongs to the sensor generations and the build sheet, and it is named here only so the map of the cloud end is complete.
The risk exchange with Entra ID Protection
The most consequential cloud touchpoint is not a detection at all, it is a handshake. Defender for Identity now computes an identity risk score, a zero to one hundred rating that became generally available in the middle of 2026, and that score is built to do one specific thing: raise the risk that Entra ID Protection carries for the same account, so that the risk-based conditional access policies you already run react to what the identity fabric sees. This is the point where the on-premises and cloud halves actually close a loop. A credential attack that the sensor catches on a domain controller is designed to lift the account’s risk in the cloud and tighten its access at the next sign-in, without a human moving between two consoles to make it happen.
Two cautions keep this honest. The first is a boundary: the scoring, the risk engine, and the conditional access that acts on it belong to Entra ID Protection, which is an Entra ID P2 capability licensed separately from this product and covered in the Entra ID Deep Dive. Defender for Identity produces a signal; it does not own the gate. The second is a genuine ambiguity you should not paper over. Microsoft’s own pages disagree about whether this unified-risk-signals exchange is still in preview and whether it requires a setting to be turned on, with one page calling it a preview feature that must be enabled and a newer one describing it as ambient with no toggle named. Until that settles, do not tell anyone it simply works. Check the Identity Protection settings directly, confirm the exchange is on, and then prove it, which the build sheet shows you how to do.
The identities you did not deploy
The cloud end has quietly grown a second population that has nothing to do with people. The inventory now enumerates non-human identities, the service principals and application identities that authenticate on their own, and as of the middle of 2026 it sees all of your Entra service principals rather than only the ones holding API permissions, and flags which of them are used by AI agents. This is preview, all of it, and it is moving quickly, so treat it as a capability to watch rather than one to build a control around yet. One precision matters for anyone who lives in Azure: Microsoft never uses the term managed identity in this surface, folding those under the broader heading of service principals, so do not go looking for a managed-identity view by name. What you get today is visibility, an inventory and the beginnings of posture over the workload identities that used to be invisible to identity security entirely, and that visibility is worth turning on and reading even while the feature label still says preview.
Where the cloud end stops
A cloud surface with this many neighbors needs its edges drawn, because the failure mode here is assuming a sibling product’s coverage is yours. Entra ID Protection is the gate and this product is the investigator; it computes the sign-in risk that conditional access evaluates, while Defender for Identity assembles the attack narrative and feeds it. Defender for Cloud Apps owns the SaaS session and the cloud sign-in telemetry, and the important consequence is that this product does not ingest Entra sign-in logs itself; the cloud authentication rows you see in hunting arrive through cloud-apps, not up through a sensor, which is why the earlier articles were careful to say the sensor reads the on-premises fabric and the cloud reads itself. Defender for Cloud and Defender for Servers own the Azure resource plane, the subscription and key-vault and workload-identity hygiene that has nothing to do with domain controllers; and although an Azure-hosted domain controller is a fully supported sensor target, that support is about the identity plane the machine hosts, not the virtual machine’s own protection, and Azure Arc is simply irrelevant to whether a sensor is eligible. Microsoft Sentinel is the last neighbor, contributing the long-retention hunting surface, and its data lake carries a licensing edge worth stating plainly: the Identity Explorer view on the identity page, still in preview, requires a Sentinel data lake license specifically, not any Sentinel workspace, so a deployment plan that treats Identity Explorer as included will stall at a purchase the reader did not budget for.
Proving a surface you never built
Which returns us to the question the whole cloud end forces. The on-premises estate ends with a clean proof, a honeytoken authentication that produces a visible alert in the queue, and the reason that test is satisfying is that you controlled the input and watched the output. The cloud end offers no such thing, because Microsoft publishes no safe way to fire its own cloud detectors on demand. There is no cloud honeytoken you can authenticate against to make an adversary-in-the-middle alert appear. So the cloud end is verified differently, by confirming that the surface is populated, that the telemetry is flowing, and that the risk exchange is compounding, and it is reported not as a single pass but as a set of standing indicators you read on a cadence. That is a different shape of proof, and it is concrete enough to deserve its own build, which is where we go next.
Defender XDR
‹ Previous: [D 3.3] Identity Posture: Fixing What the Sensors See
Next: [D 3.4.1] Build Sheet: Proving and Reporting on the Cloud End ›
