Non-Human Identities and MFA Friction at a National Retailer
A retailer has 8,000 employees, 2,400 enterprise applications and service principals, and 900 app registrations, most created self-service by developers. An audit found that 41 percent of application credentials expire in more than two years, 60 app registrations hold Graph Mail.ReadWrite or Directory.ReadWrite.All, and 300 registrations have no recorded owner. In the last quarter, 120 user-consented third-party applications were discovered, nine of which Defender for Cloud Apps later classified as high-risk. Meanwhile the service desk is receiving 3,100 MFA-related tickets per month, and the CISO wants that halved this quarter without weakening authentication. Executives currently sit in a Conditional Access exclusion group that exempts them from MFA for 'convenience'.
1. How do you prioritise remediation across 900 app registrations and 2,400 service principals?
Read the worked answer
Rank by privilege multiplied by exposure multiplied by ownerlessness - never by count.
- The 60 high-privilege registrations first. Directory.ReadWrite.All and Mail.ReadWrite are tenant-takeover and mailbox-exfiltration primitives respectively. Determine actual usage from sign-in logs and Microsoft Graph activity logs; anything with no activity in 90 days has the permission removed outright, not merely flagged. Removing an unused permission is the cheapest high-value action available.
- The 300 ownerless registrations. No owner means no accountability and no one to approve change. Drive owners through Entra ID access reviews, disable or delete orphans with zero sign-ins, and block new registrations without an owner from that point forward.
- Credential hygiene. Prefer federated credentials so there is no secret or certificate to expire. Where secrets must remain, enforce short lifetimes and automated rotation, and alert on credentials approaching expiry rather than discovering it in an outage.
- Standing controls: Conditional Access policies scoped to workload identities, app registration creation restricted to a developer group, and an approval workflow for high-impact Graph scopes.
Sequence matters: run reporting for two weeks and communicate before enforcement. Mass-revoking service principals on a Friday is how a remediation programme loses executive sponsorship.
2. How do you halve 3,100 monthly MFA tickets without weakening authentication, and what do you do about the executive exclusion group?
Read the worked answer
3,100 tickets a month is a user-experience and process design problem, not evidence that MFA is too strong.
Diagnose the mix first. Separate tickets for stale phone numbers, travellers who cannot receive push, device registrations never completed, and users repeatedly challenged on trusted devices. Each has a different fix, and 'reduce MFA' is never one of them.
Levers that cut volume without lowering assurance:
- Deploy phishing-resistant, low-friction methods - passkeys and FIDO2, Windows Hello for Business, Authenticator passwordless. Fewer prompts and fewer failures means fewer calls.
- Tune Conditional Access so compliant, low-risk devices on low-risk applications do not re-prompt, using persistent browser sessions scoped narrowly.
- Self-service: SSPR, self-service authentication method registration, and a Temporary Access Pass the service desk can issue in seconds instead of a twenty-minute verification call.
- Authentication strengths per persona rather than one global policy for everyone.
Measure tickets per 1,000 authentications, not absolute counts, or success will simply track user growth.
On the executive exclusion: remove it. Replace with a risk-based policy plus a phishing-resistant method, and a documented break-glass process for genuine emergencies. An excluded executive group is the first thing an attacker enumerates and the hardest finding to defend in an audit. Offer convenience through device compliance and longer sessions, not through an exemption.
3. Design the control model for third-party OAuth consent, given that 120 apps were consented last quarter and nine were high-risk.
Read the worked answer
Consent is the control point. User education is not a control.
- Move off unrestricted user consent. Allow user consent only for verified publishers requesting low-impact scopes; route everything else through an admin consent workflow with a request queue, named approvers and a published SLA. This single change removes most of the 120 per quarter.
- Triage what is already granted. Use app governance and OAuth app policies to surface overprivileged, unused and newly seen applications. For the nine high-risk apps, revoke the grants and then investigate post-consent behaviour: new inbox rules, mass file access, additional credentials added to the application, unusual Graph call patterns. A revoked grant does not undo what already happened.
- Detect the pattern rather than a list of apps. Alerts for non-admin consent to an application requesting Mail.Read plus offline_access, first-seen publishers, and consent events followed by anomalous Graph activity. Blocklists of known-bad app IDs decay within days.
- Contain the blast radius: Conditional Access requiring compliant devices for sessions to third-party SaaS, so a bad grant still lands in a monitored, policy-bound context.
- Own the trade-off explicitly. An approval queue slows onboarding. Staff it, publish the SLA, and publicise it - otherwise teams buy shadow SaaS that never appears in your tenant and never appears in your telemetry either.