It’s 2 a.m. and a domain controller is doing something it shouldn’t. Someone’s DCSync’d the directory, or a service account with a decade-old password just authenticated from a country you don’t do business in. Now try to answer three questions fast: what did they take, how far did they get, and how do you evict them without rebuilding the forest. If you’ve lived that night, the claim making the rounds this week won’t shock you.
In an interview published by entra.news, a Microsoft security architect argued that Active Directory is roughly ten times harder to defend than Entra ID. Two caveats up front, because the phrasing matters. First, I’m paraphrasing: I’m not putting quotation marks around “ten times harder to defend” because I can’t reproduce the sentence verbatim from the source, and I’d rather flag that than launder a paraphrase into a quote. Second, entra.news describes the person as a Microsoft security architect — I’m using the source’s framing, not upgrading it to “Principal” or “Senior” on my own authority. If the published title carries a modifier, defer to the interview over me.
Take the number as rhetoric — nobody ran a controlled experiment — but take the direction seriously, because it comes from someone who defends both for a living, not from a marketing deck. And treat it as one architect’s assessment, not Microsoft policy. Microsoft still ships, patches, and supports on-prem AD; it isn’t telling you to rip it out tomorrow.
One more piece of housekeeping, since the whole point of this desk is not lying to you. The interview makes the high-level comparison — AD is much harder to defend, and it’s about the defender’s workload, not raw feature counts. The round-by-round technical breakdown that follows — the specific Kerberos attacks, the logging plumbing, the forest-recovery pain — is my analysis, the context I’d give any admin asking “harder how, exactly?” Don’t read the itemized vulnerabilities below as a checklist the architect recited on the record. Read them as the reasons the claim holds up when you press on it.
So let’s do this as a fight, round by round, on the criteria that actually matter when you’re the one holding the pager: detection, prevention, and recovery. Running score at the bottom.
Round 1 — Prevention: can an attacker even get a foothold?
This is where the gap is widest, and it’s mostly architectural rather than a matter of you being lazy.
On-prem AD authenticates with Kerberos and NTLM. Both were designed when the threat model was “someone unplugs a cable,” not “someone runs Rubeus from a beachhead laptop.” Kerberoasting, AS-REP roasting, Pass-the-Hash, Pass-the-Ticket, Golden and Silver Tickets — these aren’t exotic zero-days. They’re the standard opening moves, and they work because the protocol hands out crackable material (service tickets encrypted with a service account’s password hash) to any authenticated user who asks. There is no native second factor on a Kerberos ticket request. The hash is the credential, and once it’s on a machine, replay is trivial.
Entra ID doesn’t have that shape of problem. There are no domain-joined tickets to forge, no KRBTGT hash whose compromise means “reset it twice and pray.” Authentication runs through OAuth/OIDC token flows, and — critically — Conditional Access sits in front of every request. Native MFA, device compliance, sign-in risk, session controls: these are policy toggles, not a project. The credential-theft equivalent in the cloud is token theft, which is real and rising, but it’s narrower, better instrumented, and increasingly blunted by token protection and phishing-resistant methods.
On prem, MFA is a bolt-on you buy, deploy, and hope covers every path. In Entra, it’s the default posture you have to actively weaken.
Round to Entra ID. Not close. Score: 1–0.
Round 2 — Detection: will you see it happen?
Logging is the one hybrid admins underrate, and it’s where the “harder to defend” framing earns its keep. AD’s native auditing is a firehose of Event IDs across every DC, off by default in the places that matter, and easy to outrun. Getting real Kerberoasting or DCSync detection means shipping Security event logs somewhere, tuning it, and usually paying for Defender for Identity to sit on the wire. Out of the box, a competent attacker moves laterally through on-prem AD leaving traces that are technically present and practically invisible.
Entra ID logs sign-ins and directory changes centrally, in one tenant, queryable, with risk scoring baked in through Identity Protection. It’s not free — the good risk detections want Entra ID P2 — but the telemetry exists as a first-class citizen rather than something you assemble from thirty domain controllers and a prayer.
I’ll add the caveat the vendor won’t lead with: cloud detection is only as good as your license tier and your willingness to read the logs. A P1 tenant with nobody watching sign-in logs is not meaningfully safer than a well-run on-prem estate with Defender for Identity. But at equivalent effort, Entra gives you more signal for less plumbing.
Round to Entra ID, on points. Score: 2–0.
Round 3 — Recovery: how bad is the 2 a.m. cleanup?
Here’s the round nobody wants to think about until they’re in it. Recovering a compromised AD forest is genuinely brutal. If KRBTGT or a Tier-0 account is popped, you’re into the double KRBTGT reset dance, possibly a forest recovery from backups you’ve hopefully tested (you haven’t), and a trust-rebuild that can take days. Microsoft has a documented AD forest recovery process precisely because it’s a project unto itself.
In Entra ID, “recovery” for a compromised identity is closer to: revoke sessions, rotate credentials, force reauth under a tightened Conditional Access policy, done in minutes from one console. There’s no forest to rebuild. The blast radius of one identity is contained to that identity plus whatever it could reach — not the cryptographic root of your entire authentication system.
Round to Entra ID. Score: 3–0. It’s a shutout.
The catch: most of you aren’t running one or the other
Here’s where the tidy scoreboard gets messy. If you’re hybrid — and you almost certainly are — you don’t get Entra’s clean posture. You get both attack surfaces, stitched together, and the seam is the dangerous part.
Password Hash Sync means on-prem hashes live in a form that matters to your cloud. A compromised Entra Connect server is a Tier-0 asset that most orgs treat like a utility box in the corner. Pass-through Auth and federation each add their own trust to abuse. And the classic hybrid own: an attacker who compromises on-prem AD — the easier target, per every round above — can often pivot into the cloud through sync accounts, seamless SSO, or forged tokens. The weak side drags down the strong one. Your Entra tenant is only as defensible as the AD forest wired into it.
Worth auditing before you argue about strategy: who’s actually still authenticating against legacy paths, and how privileged are they. Read-only, so it’s safe to run against a live tenant — but review the output, don’t pipe it into anything that changes state.
Verify the same picture in the portal under Entra admin center → Roles & admins, and cross-check hybrid identity health under Identity → Hybrid management → Microsoft Entra Connect. If your Connect server isn’t in your Tier-0 protection scope, fix that before your next threat-modeling meeting.
The verdict, and the one time AD still wins
On defensibility, this isn’t a debate. Entra ID wins prevention, detection, and recovery — a clean sweep, and I don’t think “10x” is far off as a gut-feel ratio for the effort it takes to defend each properly. The architect’s claim survives contact with reality, even if the exact multiplier is rhetoric.
But defensibility isn’t the only axis, and this is where the honest sysadmin diverges from the migration deck. Keep on-prem AD when you have to: air-gapped or OT/manufacturing networks with no cloud line of sight; legacy apps welded to Kerberos, LDAP, or NTLM that no one will refactor this decade; regulatory or data-residency constraints that make cloud-hosted identity a non-starter. Those are real reasons, not excuses — and “harder to defend” doesn’t mean “impossible to defend.” Plenty of forests run clean for years on discipline: tiered admin, gMSAs, no legacy auth, tested backups, Defender for Identity actually deployed.
So don’t read this as “migrate everything by Q2.” Read it as: every year you keep a domain controller in the auth path, you’re accepting a materially larger, harder-to-watch attack surface — and if you’re hybrid, you’re paying for both. Either shrink the on-prem footprint deliberately, or defend it like the Tier-0 liability it is. The one thing you can’t afford is to keep pretending the seam isn’t there. The attackers found it years ago.
