MCRA and Cloud Security Benchmark
Map Microsoft's security capabilities to your architecture decisions. Learn the Cybersecurity Reference Architecture and Cloud Security Benchmark controls that guide every SC-100 design choice.
What are MCRA and MCSB?
MCRA is the blueprint. MCSB is the checklist.
Imagine you’re renovating a commercial kitchen. The blueprint shows you where the ovens, fridges, ventilation, and fire suppression go — how everything fits together. That’s MCRA — it maps all of Microsoft’s security products into one architecture diagram showing how they connect and where they fit.
The checklist is the health and safety inspection form — does the kitchen have proper ventilation? Fire extinguishers? Hand-washing stations? That’s MCSB — it lists specific security controls you must implement, grouped by category (network security, identity, data protection, etc.).
An architect uses the blueprint to design the kitchen layout, then uses the checklist to verify nothing is missing.
Microsoft Cybersecurity Reference Architecture (MCRA)
MCRA is a visual architecture diagram that maps Microsoft’s security ecosystem. It organises capabilities by function, not by product name — which is exactly how an architect thinks.
Key capability areas in MCRA
| Capability Area | What It Covers | Primary Microsoft Products |
|---|---|---|
| People security | Insider risk, awareness training, human behaviour | Purview Insider Risk, Attack Simulation Training |
| DevOps security | Secure development lifecycle, supply chain | GitHub Advanced Security, Defender for DevOps |
| IoT and OT security | Industrial control, connected devices | Defender for IoT, Sentinel IoT connectors |
| Information protection | Data classification, DLP, encryption | Purview Information Protection, Purview DLP |
| Security operations | SIEM, XDR, SOAR, threat intelligence | Sentinel, Defender XDR, Threat Intelligence |
| Cloud security | Posture management, workload protection | Defender for Cloud (CSPM, CWP) |
| Endpoint security | Device protection, EDR, vulnerability management | Defender for Endpoint, Intune |
| Identity security | Authentication, authorisation, governance | Entra ID, Conditional Access, PIM |
| Network security | Segmentation, inspection, SSE | Azure Firewall, NSGs, Entra Internet/Private Access |
| Governance and compliance | Policy, regulatory compliance, risk | Purview Compliance Manager, Azure Policy |
Exam tip: Think capabilities, not products
MCRA organises by capability, not by product. The exam often describes a security need (e.g., “detect lateral movement”) and expects you to identify the right capability area first, then the specific product.
For example:
- “Detect insider threats” → People security → Purview Insider Risk Management
- “Secure the CI/CD pipeline” → DevOps security → GitHub Advanced Security / Defender for DevOps
- “Protect industrial control systems” → IoT/OT security → Defender for IoT
Don’t memorise product names in isolation — understand which capability bucket they serve.
How signals flow in MCRA
One of MCRA’s key insights is that security products don’t work in isolation. They share signals:
- Entra ID sends sign-in risk signals → Conditional Access adjusts policies
- Defender for Endpoint sends device risk → Conditional Access blocks non-compliant devices
- Defender for Cloud Apps detects shadow IT → Entra ID blocks risky apps
- All Defender products send alerts → Sentinel correlates across the estate
- Sentinel triggers → SOAR playbooks automate response
This signal flow is critical for architect-level thinking. The exam tests whether you understand that choosing one product creates dependencies and integration points with others.
☁️ Scenario: Rajan maps a client's security stack
Rajan Krishnamurthy is onboarding a new client at Skyline Security Consulting. The client has deployed 8 different Microsoft security products but configured them independently — no signal sharing, no unified incident view.
Rajan uses MCRA to visualise the intended architecture:
- Defender for Endpoint signals should flow to Conditional Access (device risk)
- All Defender alerts should feed into Sentinel (unified SIEM)
- Sentinel should trigger automated playbooks (SOAR)
- Entra ID Protection signals should inform insider risk assessments
By mapping the client’s actual configuration against MCRA, Rajan identifies 5 missing integration points. Fixing these doesn’t require new products — it requires connecting the ones they already own.
Priya Anand asks: “How did the client miss these connections?” Rajan explains: “They bought products one at a time, configured them in isolation. MCRA shows you the full picture — an architect sees the system, not just the components.”
Microsoft Cloud Security Benchmark (MCSB)
MCSB provides specific, actionable security controls organised into categories. It’s the “what should we implement?” answer to MCRA’s “what capabilities exist?”
MCSB control categories
| Category | ID | What It Covers | Key Controls |
|---|---|---|---|
| Network security | NS | Segmentation, traffic filtering, inspection | Private endpoints, NSGs, Azure Firewall, DDoS protection |
| Identity management | IM | Authentication, authorisation, SSO | MFA, Conditional Access, workload identity |
| Privileged access | PA | Admin accounts, JIT, PAWs | PIM, emergency access accounts, admin workstations |
| Data protection | DP | Classification, encryption, DLP | Sensitivity labels, CMK encryption, data-in-transit TLS |
| Asset management | AM | Inventory, discovery, lifecycle | Resource tagging, shadow IT discovery, decommissioning |
| Logging and threat detection | LT | Audit logging, threat detection, SIEM | Diagnostic settings, Defender alerts, Sentinel integration |
| Incident response | IR | Preparation, detection, containment, recovery | Incident playbooks, forensic readiness, communication plans |
| Posture and vulnerability management | PV | Scanning, patching, configuration | Defender vulnerability management, Update Management |
| Endpoint security | ES | AV, EDR, device hardening | Defender for Endpoint, attack surface reduction |
| Backup and recovery | BR | Backup strategy, testing, protection | Azure Backup, immutable vaults, recovery testing |
| DevOps security | DS | CI/CD security, code scanning, supply chain | GitHub Advanced Security, pipeline hardening |
| Governance and strategy | GS | Organisational strategy, roles, policies | Security strategy, RACI, policy frameworks |
| Aspect | MCRA | MCSB |
|---|---|---|
| Purpose | Visual map of security capabilities and signal flow | Prescriptive security controls checklist |
| Format | Architecture diagram | Control framework with IDs (NS-1, IM-2, etc.) |
| Scope | All Microsoft security products and integration | Azure and Microsoft 365 security configurations |
| Use case | Understanding how products connect and where gaps exist | Assessing compliance, measuring posture, guiding implementation |
| Industry alignment | Microsoft-specific architecture | Maps to CIS, NIST 800-53, PCI DSS, SOC 2 |
| Defender for Cloud | Shows where Defender fits in the ecosystem | Powers security recommendations and Secure Score |
MCSB and Defender for Cloud
MCSB isn’t just a document — it’s operationalised in Defender for Cloud. When you enable Defender for Cloud on a subscription:
- MCSB is applied as the default security initiative (a set of Azure Policy definitions)
- Resources are assessed against MCSB controls automatically
- Non-compliant resources generate recommendations with remediation steps
- Compliance is measured via Secure Score (percentage of controls implemented)
This means MCSB is both a design tool (for architects) and an operational tool (for engineers). The architect chooses which controls apply; Defender for Cloud enforces and monitors them.
Prioritising controls with MCSB
Not all controls are equally important. MCSB assigns severity levels, and the architect must prioritise based on:
| Factor | How It Affects Priority |
|---|---|
| Business risk | Controls protecting crown jewels get priority |
| Regulatory requirements | Mandatory controls come first (e.g., encryption for PCI DSS) |
| Attack surface | Internet-facing resources need NS controls immediately |
| Implementation effort | Quick wins (enable MFA, enable logging) before complex changes |
| Blast radius | Controls that reduce lateral movement (segmentation, least privilege) rank high |
💰 Scenario: Ingrid's compliance mapping
Ingrid Svensson at Nordic Capital Partners must demonstrate compliance with PCI DSS for payment processing and GDPR for customer data. She uses MCSB’s industry mapping:
- MCSB control DP-4 (Enable data encryption) maps to → PCI DSS 3.4 (render stored cardholder data unreadable), GDPR Art. 32 (security of processing)
- MCSB control NS-1 (Establish network segmentation) maps to → PCI DSS 1.3 (network segmentation)
- MCSB control LT-1 (Enable logging) maps to → PCI DSS 10.1 (audit trail), GDPR Art. 30 (records of processing)
Instead of implementing PCI DSS and GDPR controls separately, Ingrid uses MCSB as a unified control framework that satisfies both — reducing duplication and simplifying audits. Harald Eriksen, the compliance officer, appreciates this: “One set of controls, two regulations covered. That’s efficiency.”
Cybersecurity capabilities best practices
MCRA and MCSB together inform best practices for cybersecurity capabilities — how to design solutions for specific security functions:
| Capability | Best Practice | Why |
|---|---|---|
| Network security | Default to deny-all; use private endpoints for PaaS; centralise inspection | Reduces attack surface, prevents lateral movement |
| Identity | Enforce MFA for all users; use Conditional Access with risk signals; deploy PIM for admin roles | Identity is the primary control plane in Zero Trust |
| Endpoint | Deploy EDR on all endpoints; enforce device compliance; use attack surface reduction rules | Endpoints are the most common initial access vector |
| Data | Classify before protecting; encrypt by default; apply DLP to high-sensitivity data first | Protection without classification leads to over-blocking or under-protecting |
| Applications | Use managed identities (no credentials in code); scan dependencies; protect APIs | Application vulnerabilities are the second most common attack vector |
| Security operations | Centralise logs in Sentinel; automate common responses; retain logs for at least 90 days | Detection speed directly reduces breach cost |
Exam tip: The 'which product?' pattern
The exam frequently describes a security requirement and asks you to recommend the right solution. The pattern:
- Identify the capability area (using MCRA thinking) — is this an identity problem? Endpoint? Data?
- Identify the control category (using MCSB) — which control ID addresses this?
- Recommend the product that implements that control
Example: “An organisation needs to prevent sensitive documents from being emailed to external recipients.”
- Capability: Information protection (MCRA)
- Control: DP-2 Monitor anomalies and threats targeting sensitive data (MCSB)
- Product: Microsoft Purview DLP with Exchange Online transport rules
This structured thinking prevents you from guessing product names and grounds your answer in frameworks.
🎬 Video coming soon
Key takeaways
Knowledge check
Rajan discovers that a client has Defender for Endpoint, Defender for Cloud Apps, and Microsoft Sentinel deployed — but none are sharing signals. Sentinel receives no alerts from Defender products. Using MCRA guidance, what should Rajan recommend first?
Ingrid needs to prioritise MCSB controls for Nordic Capital Partners. The company processes payments (PCI DSS) and handles EU customer data (GDPR). She has limited resources. Which approach best aligns with MCSB guidance?
Which statement best describes the relationship between MCRA, MCSB, and Defender for Cloud?
Next up: Ransomware Resiliency by Design — design defences against the most financially devastating cyberattack, using Microsoft’s three-phase framework.