Sequencing a 90-Day Hardening Programme at Woodgrove Bank
Woodgrove Bank runs Microsoft 365 E5 for 4,200 staff with password hash sync from a single on-premises AD forest, plus 320 Azure VMs and 900 on-premises servers. Last quarter a peer bank was breached through password spray against legacy IMAP/SMTP authentication, then domain-wide compromise. The board approved a 90-day hardening programme. The CISO has 3 identity engineers and 2 detection engineers and will get no more headcount. Three initiatives are competing for the same people: (A) Microsoft Entra Privileged Identity Management for 140 privileged role assignments, (B) a Conditional Access baseline that blocks legacy authentication tenant-wide and enforces phishing-resistant MFA for administrators, (C) Microsoft Sentinel onboarding with 40 analytics rules. Separately, the payments team insists its on-premises line-of-business application must keep HTTP basic authentication because three vendor integrations cannot be changed before Q4.
1. The CISO asks you to sequence A, B and C across the 90 days. What order do you defend, and how do you justify it to a board that has just read a ransomware headline?
Read the worked answer
Order: B, then A, then C, with a short discovery step ahead of B.
The framework is risk reduction per engineer-week, measured against the threat the board is actually afraid of - not against how impressive each initiative looks.
- B first. The credible threat is identity-based and has already succeeded elsewhere in the sector. Blocking legacy auth and enforcing phishing-resistant MFA for admins removes that exact attack path, needs no new tooling, and can be validated safely for a week in Conditional Access report-only mode before enforcement. It also produces the fastest measurable evidence of progress.
- A second. Standing Global Admin is the blast-radius multiplier: if B fails, A decides whether an incident is one workstation or a forest. At 140 assignments this fits in one sprint. Do it second only because B's sign-in data reveals which admins still depend on non-interactive flows that PIM activation will break.
- C last, and scoped. Sentinel prevents nothing. Onboarding it before the identity baseline exists means tuning 40 rules against noise you are about to delete. Start with identity and endpoint tables only, then expand.
Board framing: 'We closed the door used against our peer in three weeks, then reduced what an attacker gains after entry, then bought detection.' That is a story about risk, not about tooling.
2. How do you handle the payments team's basic-authentication requirement so that it is neither an unmanaged bypass nor an operational outage?
Read the worked answer
Treat it as a formal, time-boxed risk acceptance with compensating controls - never as a Conditional Access exclusion on the tenant or on the legacy-auth policy as a whole.
- Quantify before deciding. Query Entra sign-in logs and authentication method activity for those service accounts to confirm actual protocols, source IPs and volumes. A meaningful share of these exceptions collapse once the real traffic is visible.
- Scope to identities. Exclude a named, enumerated set of accounts from the baseline policy. Never exclude the tenant.
- Layer compensating controls, because basic auth cannot do MFA:
- Restrict the network path - firewall allow-list limited to the three vendor IP ranges, no general internet exposure.
- Long machine-generated passwords issued through a vault, rotated on a schedule by automation, never in configuration files.
- Block every other client application type for those accounts so the exception cannot be reused for IMAP or POP spraying.
- Detect. A Sentinel or Defender XDR rule firing on successful authentication to these accounts from outside the allow-list, and on spray patterns across them.
- Exit criteria and owner. Written expiry tied to the vendor migration date, a named accountable executive, and monthly review in the risk register.
The anti-pattern to avoid is an open-ended 'legacy auth allowed for these 40 accounts' exclusion that nobody revisits after the migration slips.
3. The CIO wants all 140 privileged role assignments converted to eligible activations within 30 days. What failure modes do you raise, and what would you do instead?
Read the worked answer
Failure modes:
- Break-glass loss. If every assignment is eligible, an outage affecting Entra ID or the PIM service leaves nobody able to activate. Retain at least two cloud-only Global Administrator accounts with permanent assignment, excluded from Conditional Access, credentials held in a sealed offline process with tested retrieval.
- Non-human and automation paths. Some of the 140 will turn out to be service principals, scripts or emergency tooling that cannot perform interactive activation. Converting them breaks production at 02:00.
- Activation friction producing workarounds. Heavy approval chains and justification fields push admins into shared credentials or a quiet standing account. Friction is itself a security risk.
- Role creep without review. PIM without access reviews simply relocates the governance problem; entitlements accumulate and never expire.
What to do instead: classify the 140 by tier - tenant-wide roles and subscription owners first, workload-scoped roles later. Convert tier one immediately with strong approval and PIM alerts; convert the remainder over 60 days with access reviews and expiry. Pilot with ten administrators, design activation to complete in under two minutes for low-risk roles, and instrument the pilot with PIM audit logs before scaling.