Microsoft publishes several security frameworks and architectural resources that solve different planning problems. The current Microsoft SC-100 guide explicitly expects architects to align solutions with Microsoft Cybersecurity Reference Architectures (MCRA), the Microsoft Cloud Security Benchmark (MCSB), Zero Trust adoption guidance, the Cloud Adoption Framework (CAF), and the Azure Well-Architected Framework (WAF). These are complementary, not competing, layers of one security-modernization effort.
An architect gets the most value by assigning each resource a role. Zero Trust supplies the security principles. The Security Adoption Framework provides an organizational modernization method. MCRA provides reference architectures. MCSB translates best practices into cloud-security control recommendations. CAF helps organizations adopt and govern cloud at scale. WAF evaluates workload design, including its security pillar. The same program can use all of them without duplicating work.
Zero Trust is the security model that anchors the others
Microsoft frames Zero Trust around verify explicitly, use least privilege, and assume breach. These principles are intentionally product-independent. They should influence design choices even when the implementation uses third-party technology. Zero Trust tells the architect how trust decisions should work; it does not prescribe a single Microsoft SKU for every control. These principles guide how identities, endpoints, networks, applications, data, infrastructure, and AI should be secured. Zero Trust is therefore a decision model rather than a list of Azure products.
The concepts in zero-trust network access are one implementation area, but Microsoft Zero Trust is broader than network access. Identity assurance, device health, data protection, privileged access, segmentation, monitoring, and continuous risk evaluation all belong to the same model.
The Security Adoption Framework organizes the modernization program
Microsoft’s current Security Adoption Framework is a structured model for security modernization across business strategy, security disciplines, and technology pillars. It replaces the tendency to run identity, endpoint, data, network, and security-operations projects independently. Business scenarios and technology pillars help organizations connect security investment to outcomes and accountable roles. It helps leaders, architects, and practitioners translate Zero Trust principles into prioritized programs instead of treating security improvement as a collection of unrelated product deployments.
The framework integrates older Microsoft guidance and aligns business scenarios with technical implementation. Use it when the challenge is sequencing, ownership, operating model, and organizational adoption rather than choosing one technical control.
MCRA provides end-to-end reference architectures
The Microsoft Cybersecurity Reference Architectures provide technical architecture patterns across the modern enterprise: hybrid infrastructure, multicloud, identities, endpoints, data, applications, operational technology, AI, and more. The diagrams can expose missing integration points—for example, identity signals that never reach policy enforcement or security telemetry that is collected but not connected to operations. Use them as architecture conversation tools, not only as presentation slides. The June 2026 MCRA update further aligned the material with Microsoft’s newer security-adoption model.
Use MCRA as a target-state and integration reference. It helps teams see how security capabilities connect, where control planes sit, and how Microsoft and third-party technologies can fit into a coherent design. It is not a configuration benchmark or a mandatory product bill of materials.
MCSB turns broad principles into cloud control recommendations
The Microsoft Cloud Security Benchmark provides prescriptive recommendations for cloud-centric security areas such as network, identity, privileged access, data protection, asset management, logging, incident response, and posture management. Microsoft’s v2 benchmark is currently in preview, so architects should record which benchmark version their internal standards map to and avoid silently mixing control identifiers across versions. It maps Microsoft guidance and industry practices into controls that can be applied to Azure and multicloud workloads.
Use MCSB when an architect needs to ask whether a workload or cloud environment implements appropriate security controls. It is especially useful for turning a broad principle such as least privilege into concrete questions about privileged access, network security, asset management, logging, posture management, and data protection. MCSB recommendations can then be mapped to policy-as-code, Defender for Cloud recommendations, or internal standards. The current benchmark also connects to Microsoft’s broader guidance such as CAF, WAF, the Secure Future Initiative, and industry standards. It complements MCRA by making controls more prescriptive.
CAF governs how the organization adopts cloud
The Cloud Adoption Framework covers strategy, planning, ready, adopt, govern, secure, and manage activities across the cloud adoption journey. Its security guidance helps organizations build a cloud-security strategy, define roles, integrate Zero Trust, and use Microsoft architectural guidance during adoption.
Use CAF when security decisions must be integrated with landing zones, governance, platform teams, workload migration, operating models, and cloud-management processes. Security architecture that ignores the cloud operating model often fails because guardrails, ownership, and exception handling are not built into the adoption process. CAF connects security to the way cloud is actually organized and funded. It answers a broader transformation question than MCSB: how should the organization adopt and operate cloud in a controlled way?
WAF evaluates the quality of individual workloads
The Azure Well-Architected Framework evaluates workloads across reliability, security, cost optimization, operational excellence, and performance efficiency. Review findings should feed back into platform standards: if many workload teams repeatedly fail the same security area, the issue may belong in CAF governance or platform guardrails rather than in dozens of local remediation plans. The security pillar helps teams review the architecture and operation of a specific workload against principles such as segmentation, identity, data protection, and security operations.
Use WAF at workload level. Security is one pillar, but a secure design still has to coexist with reliability, cost, performance, and operational excellence. A control that meets security intent but makes a critical workload unrecoverable or operationally unmanageable can create another form of risk. WAF helps the application team balance those architectural tradeoffs explicitly. An organization can follow CAF for enterprise cloud adoption while using WAF reviews for individual applications. MCSB can provide deeper control guidance when a WAF security review identifies an area that needs specific technical improvement.
The frameworks map from strategy to architecture to controls
A useful sequence is: business outcomes and Zero Trust principles define the security direction; the Security Adoption Framework structures the modernization program; MCRA provides target architectures; CAF shapes cloud adoption and governance; WAF evaluates workloads; MCSB supplies cloud-control recommendations and measurable implementation guidance. The sequence also clarifies ownership: executives and security leaders set direction, architects design target state, platform teams implement guardrails, and workload teams validate their solutions.
The sequence is not strictly linear. A WAF review can reveal a platform gap that changes CAF governance. An MCSB control gap can trigger an MCRA architecture decision. The value comes from using the right lens for the problem, not from forcing every team through one document in one order.
Avoid turning frameworks into duplicate compliance checklists
Teams often waste effort by copying every framework into a spreadsheet and tracking the same control several times. Build one internal control or architecture catalog with a stable identifier for each requirement, then map MCSB, WAF, regulatory obligations, and enterprise policy to it. That lets one piece of evidence satisfy multiple mappings and keeps remediation ownership clear. Instead, create one internal control catalog or architecture standard, then map Microsoft guidance and external requirements to those internal controls. This keeps ownership and evidence consistent.
Use MCSB and WAF as inputs rather than parallel sources of truth. Use MCRA diagrams as architecture references rather than another compliance register. Use CAF and Security Adoption guidance to organize governance and accountability. The framework should reduce ambiguity, not generate competing lists. Assign each internal control one owner, one evidence source, and one exception path, then map multiple Microsoft frameworks to that control. This keeps implementation teams focused on the actual security outcome instead of reconciling duplicate wording.
Use one architecture narrative to connect all the guidance
An SC-100 architect should be able to explain why the organization follows Zero Trust, how security modernization is governed, what the target architecture looks like, which cloud controls are required, and how individual workloads are reviewed. The same explanation should make sense to leadership and engineering teams: business outcomes at the top, architecture and control requirements in the middle, and product configuration at the implementation layer. Microsoft’s frameworks provide different pieces of that story.
The practical output is one coherent architecture and operating model: shared principles, defined roles, target-state diagrams, cloud guardrails, workload standards, measurable controls, and an adoption roadmap. Add a review cadence so changes in Microsoft guidance, new benchmark versions, or new AI and security capabilities are assessed without restarting the entire security program. When each Microsoft framework has a clear purpose, teams can use all of them without confusion or redundant governance, and they can explain how strategy, architecture, controls, and workload reviews connect.
A practical way to combine the frameworks is to start with a real workload. Zero Trust says the workload should verify explicitly and use least privilege. MCRA shows how identity, network, data, endpoint, and security operations connect around it. CAF determines the platform guardrails and ownership model. WAF tests whether the workload design meets security alongside reliability and operational goals. MCSB supplies concrete control recommendations. The Security Adoption Framework then helps leaders sequence modernization work when gaps span several teams.
The framework map should be versioned like any other architecture standard. Microsoft updates benchmarks, reference architectures, and adoption guidance as products and threats change. Record which MCSB version and WAF guidance an internal standard maps to, review material updates on a defined cadence, and preserve stable internal control identifiers so product-document changes do not force teams to rewrite every policy, exception, and audit record.