Solution Atlas
EverydayUser storyConsultative playbook

Our perimeter model is failing and we need a Zero Trust strategy, not just MFA

The CISO has been told 'we have Zero Trust' because MFA is enabled. The auditor is asking deeper questions: device compliance, conditional access, microsegmentation, data classification. The current posture has gaps in every Zero Trust pillar and there is no end-to-end programme.

Trigger
Audit questions on Zero Trust posture; insurer pressure on architectural maturity.
Good outcome
Zero Trust reference architecture mapped to estate, gaps identified per pillar, phased programme launched with explicit pillar owners.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·Auditor or insurer asking deeper Zero Trust questions than MFA coverage
  • ·"We have Zero Trust" claimed but no pillar-by-pillar evidence
  • ·Identity controls partial — MFA present but no risk-based Conditional Access
  • ·Device compliance enforcement uneven across the estate
  • ·Data classification minimal; apps not consistently gated

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.How would you describe your Zero Trust posture today, pillar by pillar — identity, device, network, application, data?

    WhyForces a structured answer. "We have MFA" is not a Zero Trust answer; this question reveals the gaps.

  2. 2.What does "we have Zero Trust" mean when your security team says it today?

    WhySurfaces the gap between aspiration and posture.

    Listen for: “MFA is enabled” · “Conditional Access is partial” · “we are working on it”

  3. 3.Where is the weakest link — identity, device, network, application, or data?

    WhyAnchors the prioritisation. Often the weakest pillar drives the programme.

  4. 4.Has the auditor or insurer specified controls or just outcomes?

    WhyForcing-function. Specified controls drive an explicit mapping; outcomes leave room to design.

  5. 5.What is your appetite for tightening Conditional Access — block unmanaged devices, require device compliance?

    WhyTests organisational change-management capacity.

  6. 6.Have you done a Zero Trust maturity assessment (Microsoft Zero Trust Maturity Model or CISA ZTMM)?

    WhyIf yes, anchor on it. If no, the engagement starts there.

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

MFA enabled tenant-wide but Conditional Access not risk-based. Intune partial; device compliance not enforced for all corporate access. Network: traditional perimeter with VPN, microsegmentation absent. Data classification minimal — Purview Information Protection in pilot at best. Apps not gated by Conditional Access. No single Zero Trust programme; pillars owned (or not owned) by separate teams.

Typical concerns

  • ·No defensible answer to "what is your Zero Trust posture?"
  • ·Conditional Access exists but does not enforce device compliance
  • ·Network perimeter still load-bearing in the security model
  • ·Sensitive data scattered without classification or DLP
  • ·Pillars without explicit owners; no programme cadence

Capability gaps

  • ·Identity pillar with risk-based Conditional Access and PIM
  • ·Device pillar with Intune compliance enforcement
  • ·Network pillar with microsegmentation or ZTNA
  • ·Data pillar with sensitivity labels and DLP
  • ·App pillar with Conditional Access gating
  • ·Programme cadence with explicit pillar owners
Target architecture

Entra ID P2 enforces risk-based Conditional Access tenant-wide with PIM for privileged roles. Intune enforces device compliance for all corporate access. Defender for Cloud provides the secure-score baseline including network and workload posture. Purview Information Protection classifies content tenant-wide with DLP on key surfaces. Apps gated by Conditional Access. Each pillar has a named owner; the Zero Trust programme runs a quarterly cadence with cross-pillar review.

Key capabilities

  • Identity: P2, PIM, risk-based Conditional Access
  • Device: Intune compliance enforced
  • Network: microsegmentation in cloud + ZTNA for users
  • Data: sensitivity labels + DLP
  • App: Conditional Access gating
  • Programme: pillar owners + quarterly cadence

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.Roll-out shape — pillar-by-pillar vs concurrent multi-pillar

    Pillar-by-pillar (identity → device → data → network → app)

    When it fitsLimited programme capacity; appetite for sequential maturity.

    Trade-offsMulti-year timeline; gaps remain visible during transition.

    Concurrent multi-pillar

    When it fitsStrong programme office; multiple workstreams in parallel; auditor pressure on all pillars.

    Trade-offsHigher coordination overhead; risk of stalling one pillar.

    Default recommendationPillar-by-pillar starting with identity (highest signal); add device in parallel from month 3.

  2. Decision 2.Scope — full estate vs production-first

    Full estate

    When it fitsMature organisation; appetite for change management at scale.

    Trade-offsLonger timeline; broader user impact.

    Production-first

    When it fitsHigh-velocity programme; appetite to leave non-production at baseline.

    Trade-offsTwo operating models during transition.

    Default recommendationProduction-first for the first 12 months; expand to non-production as confidence grows.

  3. Decision 3.Enforcement — hard (block) vs soft (audit and warn)

    Hard block

    When it fitsAuditor or insurer demands immediate posture change.

    Trade-offsUser friction; emergency-access path needed.

    Soft (audit + warn)

    When it fitsChange-management runway available; appetite for gradual tightening.

    Trade-offsPosture stays advisory during transition.

    Default recommendationSoft for the first 90 days per pillar; hard from day 91.

Low-risk trial — proof of value

8-week Zero Trust maturity assessment + identity & device pillars validated

8 weeks

Zero Trust Maturity Model (Microsoft ZTMM or CISA ZTMM) assessment of the estate. Identity pillar: Entra ID P2 with risk-based Conditional Access and PIM rolled out for privileged users. Device pillar: Intune compliance enforced for one business-priority application set. Defender for Cloud secure-score baselined for the multi-pillar view. Programme charter authored with pillar owners and quarterly cadence.

Success criteria

  • Maturity assessment delivered with gaps mapped per pillar
  • Identity pillar at Advanced maturity for the privileged-user tier
  • Device compliance enforced for the trial application set
  • Programme charter signed off with pillar owners named

InvestmentEntra ID P2 ~€8.30/user/month scoped to privileged users (~150 seats typical). Existing M365 E3/E5 estate untouched. Estimated ~€2–4k/month for the trial scope.

Proof metrics

  • ·Zero Trust maturity score baselined and trending up
  • ·Standing privilege reduced by 80%+ via PIM
  • ·Device compliance score above 90% on the trial scope
  • ·Cross-pillar incident response measurable

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Identity pillar — PIM, Identity Protection, risk-based Conditional Access. The most-asked Zero Trust capability and the highest-signal SOC input.

Why for this story

Conditional Access foundation underneath P2. Everyone needs P1; only privileged users need P2.

Why for this story

Secure-score baseline across network and workload pillars. The cross-pillar posture dashboard the audit references.

Why for this story

Data pillar — sensitivity labels + DLP. The classification baseline that makes data-pillar enforcement defensible.

Back to Zero Trust architecture