Entra ID CIS Benchmark
Audit — v2

The Problem

The v1 CIS auditor covered the on-prem Windows side — 60 controls on a Domain Controller via WinRM and PowerShell. It said nothing about the cloud: Microsoft Entra ID, where identities, MFA, Conditional Access, and privileged-access controls actually live in a hybrid setup.

v2 extends the same JSON-driven, deterministic engine to the tenant. Instead of PowerShell over WinRM, the collector pulls live tenant state from the Microsoft Graph API using a service principal, and the same comparison engine evaluates it against Entra ID / CIS controls — no code changes to the core, and no AI model invoked during the audit. What follows is the real result of that audit on a Microsoft 365 Developer Program tenant: what the platform let us read, what it let us fix, and where it refused the write.

Results — Verified, Not Claimed

Final state of the remediated Developer Program tenant, re-read from the live API after each write. Green changed as intended; red blocked at the platform tier.

Technical Note — the Developer-Tenant Platform Tier

A distinct, reusable finding about how Microsoft 365 Developer Program tenants expose Conditional Access. This is a different kind of ceiling from the P1/P2 feature-level restrictions (PIM, Identity Protection) — and it matters for anyone building or testing automation against Developer tenants.

Two separate ceiling classes:

1. Feature-level (P1/P2): the entire capability is absent until licensed — PIM, Identity Protection, PIM-eligible roles. These return AadPremiumLicenseRequired and are simply not evaluated; there is no write surface to probe.
2. Platform-tier (CA + registration-enforcement): the API surface exists and is readable in a Developer tenant, but the write path is gated by tenant class. The read succeeds (200); the write is refused (403 for CA, 400 for registration) — a licensed-capability gate on the mutation, not an absence of the feature.

Case Study

Three findings, in the order they were discovered. Every number below was verified from the live tenant (re-read after each write), not from intent.

a. MFA Method Hardening — applied & verified

The free-tier MFA method configuration is writable in a Developer tenant, and this fix landed and persisted — PATCH authenticationMethodsPolicy returned HTTP 204, confirmed by a follow-up read.

Effect: the two most phishable strong-auth methods (email one-time code, 6-hour TAP) are off the tenant; any completed MFA must be app- or certified-hardware-backed.

b. The P2 Assumption Error — caught & corrected

An earlier pass of this audit recommended two fixes that assumed a paid/licensed capability was provisionable in a no-license Developer tenant — until challenged to verify the claim against live tenant data:

That was incorrect. This is a Microsoft 365 Developer Program tenant (subscribedSkus = [], assignedLicenses = 0/23) — it cannot provision P1/P2 at all (no trial, no self-serve subscription). The read API for P2-gated features still works; the write / activation path is gated by tenant class — the same split documented in the technical note above.

How it was caught:

1. The license inventory was empty before any fix was written — subscribedSkus: [], 0/23 user licenses assigned. The "assign P2" fix had nothing to assign.
2. The write probes returned 403 / 400, not success — the first signal this was a gate, not a payload bug.
3. The read-vs-write contrast — CA GET → 200 while CA POST → 403 under the same scoped token — proved a tenant-class gate, not a scope / consent problem.

c. The CA / Registration-Gate Discovery — attempted, blocked, root cause identified

Two items could not be remediated in this tenant, with the exact responses:

• MFA registration-enforcement (C1 gate): PATCH authenticationMethodsPolicy → registrationEnforcement…state = active → HTTP 400 "The configured RegistrationEnforcement is invalid." Retried on v1.0 and beta across four payload shapes — consistently rejected.
• Conditional Access policy creation (C2): POST conditionalAccessPolicies → HTTP 403 "Your tenant is not licensed for this feature. Please upgrade your subscription." Retried with enabled, disabled, and minimal-body variants — consistently rejected.

Root cause: both are licensed capabilities the Developer Program tier does not expose for writes. Not scope (the token carried Policy.ReadWrite.ConditionalAccess / Policy.ReadWrite.AuthenticationMethods), not consent (admin-consented), not payload (multiple shapes). A platform-tier gate.