22,000 Accounts and Five Months
An insurer with 4,500 employees holds 22,000 accounts across 60 applications. Twenty applications are federated to the corporate identity provider; the other forty use local credentials with differing password policies. The service desk resets 900 passwords a month. The quarterly access review takes six weeks because managers approve everything - in the last cycle 98% of entitlements were re-certified, and 1,100 accounts had no logon in 90 days. An audit finding cites active accounts belonging to terminated staff. The CISO's three priorities are phishing-resistant MFA, reducing standing privilege in the three crown-jewel applications, and passing the next audit in five months. The identity team wants to finish the SSO migration before addressing certification quality.
1. Sequence the work against the five-month deadline and justify what you deliberately defer.
Read the worked answer
Rank by audit exposure × containment value ÷ time to deliver, not by architectural completeness.
Days 0–30 - orphaned accounts (the actual audit finding). This is a process defect, not a technology project. Reconcile the HR system of record against the IdP and all 60 applications, disable the accounts belonging to leavers, and automate the leaver trigger from HR. It is fast, it is cheap, it directly closes the finding, and it cannot fail for technical reasons. Deferring this to chase SSO completion would be answering a question the auditor did not ask.
Days 30–90 - dormant and excessive accounts. Disable the 1,100 accounts with no logon in 90 days (after a notification and a defined reactivation path), then attack standing privilege in the three crown-jewel applications: remove permanent admin rights, replace with just-in-time elevation or a managed privileged-access tier, and put phishing-resistant MFA on those paths first.
Days 90–150 - certification redesign (see next task) and audit evidence pack.
Deliberately deferred: completing SSO for all 40 local applications. It continues in the background, prioritized by user count and risk, but it is a multi-quarter effort and is not what the finding is about. Sequencing SSO first would trade a certain, cheap audit remediation for an uncertain, expensive one.
Note what is not deferred: phishing-resistant MFA starts immediately on privileged and crown-jewel paths, because it is the highest-value slice and does not need the SSO programme finished.
2. Why is a 98% re-certification rate evidence of a broken control rather than good hygiene, and what would you change?
Read the worked answer
The number is the tell. A review that approves almost everything is not exercising judgement; it is producing the artefact of a review without the function of one. Managers faced with 200 line items they do not understand, in a tool they use once a quarter, will approve by default - approval is the path of least resistance and carries no consequence.
Specific defects and fixes:
- Wrong reviewer, wrong granularity. A manager cannot judge an entitlement to a specific database role. Scope the review to what matters: 100% of privileged and crown-jewel entitlements, plus a risk-ranked sample of the rest, and route application-specific entitlements to the application owner who can actually evaluate them.
- The reviewer lacks data. Give usage evidence at the point of decision: last-used date, frequency, peer comparison. Asking someone to certify without usage data guarantees rubber-stamping.
- No default action. Make 'no response' result in revocation, not automatic re-certification. This alone converts approval rates into decisions.
- Measure the output that matters: revocations and modifications per cycle, and the manager-level approval-rate distribution. A manager at 100% across every cycle gets coaching, not credit.
- Continuous instead of quarterly where the tooling allows - a quarterly six-week slog over 22,000 accounts is unmanageable by design.
Judgement to state explicitly: driving the re-certification rate down is the success metric, and you should tell the audit committee that in advance, or the first cycle after the fix will look like a regression.
3. What does 'phishing-resistant MFA' actually require, and what do you do for the local-credential applications that cannot support it?
Read the worked answer
Phishing-resistant means the credential is bound to the origin - FIDO2/WebAuthn security keys or platform authenticators, or certificate-based authentication. Anything that requires the user to read a code and type it into a page they reached by clicking a link is phishable, including TOTP and push-with-number-matching (which defeats naive push bombing but not a well-built adversary-in-the-middle proxy).
Tier the rollout:
- Privileged and crown-jewel access: hardware keys, no fallback, this quarter.
- General workforce on federated apps: platform authenticators via the IdP, with conditional access.
- High-risk sign-ins (new device, unusual geography, vendor/contractor): step-up to a hardware key.
For the 40 local-credential applications that cannot federate or support modern authentication:
- Do not let them define the standard. The user gets strong MFA at the IdP; the legacy app must not be the weak link for the same account.
- Front them - put the application behind a reverse proxy / identity-aware gateway that enforces modern MFA and then presents a managed, vaulted credential to the legacy app, so the user never handles the legacy password.
- Where fronting is impossible: network-restrict the app to a jump host or VDI, vault the credential, rotate it, and log every session. Treat the app as a compensating-control case in the risk register with a migration or decommission date.
- Prioritize retirement. Applications that cannot support modern authentication are also the ones with the worst patching; give each an owner and a decom date rather than an open-ended exception.
State the trade-off plainly: proxy fronting adds a dependency and some latency, and where the vendor refuses, you accept network restriction as a weaker interim control - documented, time-boxed, and reported.