What is the Microsoft Cloud Security Benchmark (MCSB)?

The Twelve Domains

Network Security (NS). Segmentation, private endpoints, network security groups, DDoS protection, and restricting public exposure of platform services.

Identity Management (IM). Centralizing identity in Entra ID, enforcing strong authentication, restricting application and service principal permissions, and eliminating standing credentials in code and configuration.

Privileged Access (PA). Limiting the number of highly privileged accounts, using Privileged Identity Management for just-in-time activation, and protecting the administrative plane.

Data Protection (DP). Classification, encryption at rest and in transit, key management, and monitoring of sensitive data movement.

Asset Management (AM). Inventory of every subscription, resource, and service; approved-service governance; and removing resources nobody owns.

Logging and Threat Detection (LT). Enabling and centralizing logs, retaining them long enough to investigate, and connecting detection to a monitored SIEM or Defender workspace.

Incident Response (IR). Preparation, detection, containment, and post-incident review, with notification paths defined before they are needed.

Posture and Vulnerability Management (PV). Secure baseline configuration, vulnerability scanning, and remediation cadence for compute, containers, and platform services.

Endpoint Security (ES). EDR coverage on virtual machines and centralized anti-malware management.

Backup and Recovery (BR). Automated backups, immutability, isolation from the production identity plane, and tested restores.

DevOps Security (DS). Securing the pipeline, secrets management, and infrastructure-as-code review.

Governance and Strategy (GS). The program layer: roles, policies, and the risk decisions that everything above implements.

Control IDs and Mappings

Each control carries an identifier such as IM-1 or LT-4 and publishes its correspondence to NIST SP 800-53 Rev 5 control IDs, CIS Controls v8 safeguards, and PCI DSS requirements. That mapping is what makes MCSB useful beyond the Azure console. A finding recorded against LT-4 (enable and retain logs) is also a finding against 800-53 AU-11 and CIS Control 8, without anyone doing the translation by hand.

Secure Score: What It Measures

Defender for Cloud evaluates every subscription against MCSB recommendations and produces Secure Score, a percentage weighted by the severity Microsoft assigns each recommendation. The score rises as recommendations are remediated or exempted. It is displayed prominently, it is easy to report, and it is the single most misunderstood number in Azure governance.

What the score measures: the proportion of MCSB recommendations the environment currently passes, across the subscriptions Defender for Cloud is enabled on, excluding anything an administrator has exempted. What the score does not measure: whether an attacker holds a valid credential, whether a service principal was granted excessive permissions six months ago and still holds them, whether a storage account was public last quarter and exfiltrated before it was fixed, or whether the subscriptions with the worst posture are simply not enrolled. A 90 percent Secure Score on the three subscriptions in scope says nothing about the fourth.

The correct use of Secure Score is trend tracking within one environment. The incorrect use is presenting it to a board or an acquirer as a grade. Every acquirer's technical reviewer knows that exemptions and scope move the number, and will ask to see the exemption list and the subscription coverage before crediting it.

MCSB and the CIS Azure Foundations Benchmark

The two are complementary. The CIS Azure Foundations Benchmark is third-party consensus guidance focused on specific configuration settings, with Level 1 and Level 2 profiles. MCSB is Microsoft's framework, broader in scope, covering program-level controls such as incident response and governance as well as settings. Microsoft publishes the mapping between them, and Defender for Cloud can assess against either or both. The practical pattern is to use MCSB as the taxonomy, because it is native to the console, and CIS as the detailed checklist where it goes deeper.

MCSB Is Not Microsoft 365

A frequent confusion. MCSB covers Azure infrastructure and platform services and, through connectors, other clouds. It does not cover Microsoft 365 tenant configuration: Exchange Online, SharePoint, Teams, and the identity settings that govern them. Those are the domain of the CIS Microsoft 365 Benchmark, CISA SCuBA, and Microsoft's separate Secure Score for Microsoft 365. Most mid-market organizations run both surfaces and are exposed on both. An Azure environment can be well hardened while the Microsoft 365 tenant next to it, where the money actually moves through email, is not.

What MCSB Does Not Ask

MCSB, like every configuration framework, describes a desired state and checks whether the environment matches it. It does not ask whether the environment was compromised before it matched. An Azure subscription can pass every Identity Management and Privileged Access recommendation today while a service principal granted excessive permissions last year continues to read data. A Logging and Threat Detection score of 100 percent means logs are collected and retained; it does not mean anyone has read them for the sign-in from an unfamiliar country that happened in March. Configuration assessment and compromise assessment are separate disciplines. A board that receives only the first has been told about the locks, not about who is in the building.

Executive Implications

For a CFO, MCSB is the framework behind a number that will appear in IT reporting whether or not anyone asked for it. Knowing that the number counts passed recommendations, that exemptions and scope move it, and that it is silent on compromise, is enough to ask the right follow-up questions. For a GC, MCSB is the standard Microsoft itself publishes for its platform, which makes it the reasonableness benchmark opposing counsel will reach for after an Azure-hosted incident. For a PE operating partner, a Defender for Cloud assessment across portfolio Azure subscriptions is inexpensive, consistent, and produces a remediation list engineers can execute from the console. It should be paired with a Microsoft 365 assessment and a compromise assessment, or it will produce confidence the environment has not earned.

Related Reading

• What are the CIS Benchmarks?
• What is CISA SCuBA?
• What is NIST SP 800-53?
• What is Security Posture Management?
• What is a Compromise Assessment?

Real-World Example: The Score Was 84 Percent

A pattern from Cloudskope's Azure assessment work. A PE-backed software company reported an Azure Secure Score in the mid-80s to its operating partner as evidence that the infrastructure was in good shape. The number was accurate. It reflected the two production subscriptions where Defender for Cloud had been enabled and where the engineering team had worked through the recommendation list.

The assessment found two further subscriptions, created by a former contractor for a proof of concept and never decommissioned, that were not enrolled in Defender for Cloud and therefore not in the score. One contained a storage account with public blob access holding a database export. The other held a virtual machine with an internet-facing management port and no EDR agent. Neither had been touched in over a year. Neither appeared in any report leadership had seen.

Both were Asset Management failures in MCSB terms: the framework's first instruction is to inventory every subscription and resource, precisely because posture measured on a partial inventory is not posture. The remediation took a day. The finding that the operating partner had been reading a score computed on half the environment took longer to absorb.