security-architecture

Security Architecture (Zero Trust & MCRA)

Security architecture defines how identity, endpoints, data, apps, infrastructure, and network controls combine to protect an organisation - anchored to Zero Trust and the Microsoft Cybersecurity Reference Architectures (MCRA), with delivery scaffolding from the Cloud Adoption Framework Secure methodology and workload-level rigour from the Well-Architected Framework Security pillar.

When to use

Designing an end-to-end security target state, aligning a multi-year roadmap to a recognised framework, or reviewing an architecture for gaps before a major programme of work.

Do not use this skill for:

• Tactical product configuration (use the product-specific skill, e.g. defender-xdr, sentinel)
• SOC tooling architecture only (use unified-secops-platform)
• Single-workload code review (use threat-modelling)

Pick the right framework for the conversation

Question being asked	Use this framework	Output
What is our 3-year security target state?	MCRA + CAF Secure	Capability map + roadmap
What capabilities cover identity / endpoints / data / apps / infra / network?	Zero Trust six pillars	Pillar maturity heatmap
How do we deliver the programme (strategy → operate)?	CAF Secure methodology	Workstream plan
Is this single workload designed securely?	Well-Architected Security pillar	Workload review
What threats apply to a specific design?	STRIDE / SDL (use threat-modelling)	Threat model
Are we meeting a regulatory baseline?	Microsoft Cloud Security Benchmark	Compliance evidence

Rule of thumb: Zero Trust is the principles layer. MCRA is the capability layer. CAF Secure is the delivery layer. Well-Architected is the workload layer. A real architecture uses all four - do not try to substitute one for another.

Approach

1. Anchor on Zero Trust principles first - Verify explicitly, use least-privilege access, assume breach. Every later decision must trace back to one of these. Verify: every control in your design can be tagged to one of the three principles. If it cannot, ask why it exists.
2. Map the six Zero Trust pillars - identity, endpoints, data, apps, infrastructure, network, with visibility/analytics and automation across all. Score current maturity per pillar (Traditional / Advanced / Optimal) so investment lands where the gap is widest. Verify: pillar heatmap shows clear deltas; you can name the top two pillars to invest in.
3. Validate identity is the primary control plane - if identity is weak, no other pillar compensates. Confirm MFA coverage, privileged access design (PIM, PAW), and Conditional Access posture before investing heavily in network, data, or endpoint pillars. Verify: % of human accounts behind phishing-resistant MFA and % of privileged accounts in PIM are baselined and on a roadmap.
4. Anchor capabilities to MCRA - Use the Microsoft Cybersecurity Reference Architectures to map Microsoft products (Defender, Sentinel, Entra, Purview, Intune, Defender for Cloud) to the functions they cover and to validate no capability is missing or duplicated. Verify: MCRA poster overlaid with your current/planned products shows zero unaddressed functions in your scope.
5. Build defense in depth - layer preventive, detective, and responsive controls so no single control failure equals a breach. For each asset class, name at least one preventive and one detective control. Verify: removing any one control still leaves a detection or compensating control in place.
6. Sequence the roadmap by risk and dependency - Current state → target state per pillar, ordered so prerequisites land first (e.g. identity hygiene before data classification, log ingestion before XDR, posture management before automation). Verify: roadmap shows ordered milestones with named owners and risks; not a flat backlog.
7. Build monitoring and response in, not on - the SIEM/XDR architecture is part of the design, not a follow-up project. Confirm log sources, retention, and response handoffs. Verify: every pillar produces signals into a documented detection pipeline.