4,200 Non-Human Identities and a Push-Fatigue Pattern
Corvus Manufacturing has 4,200 non-human identities: 2,900 service accounts, 800 CI/CD tokens, 340 vendor integrations and 160 automation scripts. Of the service accounts, 1,900 use credentials older than 12 months, and 340 hold domain-admin or cloud-global-admin equivalent rights. None of them can use MFA. Separately, the IAM team reports 40 MFA reset calls a day to the service desk, and last month three users approved push notifications after repeated prompts at 02:00 from an unrecognised location; a fourth denied them and then reported nothing. In March, a new observability vendor was granted a tenant-wide read token 'temporarily' to shorten onboarding, and it has not been reviewed since. The identity team has four engineers and a quarterly access-review commitment it is already behind on.
1. Prioritise the non-human identity remediation for a four-engineer team, and justify why rotation is not your first move.
Read the worked answer
Score each population by privilege, reachability and how cheaply the risk can be structurally removed.
First: the 340 privileged accounts. These are the ones whose compromise ends the company. Split them into decomposable, over-privileged and legitimately privileged. Decommission what is unused - 90 days of cloud IAM last-used data and Windows service logon events settle that quickly. For the rest, remove standing global admin and scope permissions to the actual API calls observed, then vault the credential with just-in-time checkout. Standing privilege reduction beats rotation because it survives the next compromise.
Second: the 800 CI/CD tokens. A leaked pipeline token is a software supply-chain event, not just a data event. Prefer workload identity federation and short-lived tokens over static secrets, which deletes the 12-month-old-credential problem instead of managing it.
Third: rotation of the 1,900 stale credentials, prioritised by internet reachability. Rotation is deliberately not first: rotating 1,900 credentials with a four-person team will break integrations, generate an outage, and leave you with the same standing privileges 12 months later. Rotation is the cleanup, not the fix.
Fourth: vendor integrations, where the contract and scope review usually take longer than the technical change. Start that paperwork now because it has a long lead time.
2. Design detection for the push-fatigue pattern and for abuse of the helpdesk reset process, including what would have caught the three approvals last month.
Read the worked answer
Two attacks, two detection stories, one common data source: the identity provider's authentication log joined with the service desk's ticket system.
Push fatigue: alert on push count per identity per hour above a threshold, and specifically on the sequence deny-then-approve followed by a successful sign-in. Enrich with ASN and geo novelty for that user and device-fingerprint change. Last month's pattern - repeated prompts at 02:00 from an unrecognised location followed by an approval - matches this on every axis; the failure was that nobody was watching that sequence, not that the evidence was missing.
Helpdesk abuse: the classic move is a reset request followed by authentication from a new location within minutes. Correlate reset tickets to subsequent sign-ins on the same identity and alert on reset-plus-new-device within a short window. Add process controls: verified callback to a number on record, a cooldown after reset, and a supervisor approval for resets on privileged or executive accounts.
Structural fix: move the population to phishing-resistant FIDO2 or number-matching, which removes the approve-anything reflex rather than detecting it. Detection buys the time to get there. Track two metrics monthly: push prompts per user per day, and the count of reset-to-new-device sign-ins that were not caught by policy.
3. What governance would you put on the vendor token granted in March, and how do you clean up the current one without breaking the integration?
Read the worked answer
The immediate problem is scope, not existence: a tenant-wide read token issued for an onboarding shortcut will keep reading after the project ends.
The cleanup: inventory what the token actually touches over a 30-day window, then replace the tenant-wide grant with a scoped application registration - specific Microsoft Graph or cloud API permissions, certificate credential rather than client secret, and a named service principal owner. Cut over behind a feature flag, verify the integration's calls succeed against the narrower scope, then revoke the original. Doing it in this order means the old token stays valid until the new path is proven, so the integration does not break and the vendor does not get a reason to ask for admin again.
Ongoing governance: every non-human identity carries an owner, a purpose and an expiry; app consent policy restricts who can grant tenant-wide permissions and requires review; access reviews every quarter for vendor integrations with per-permission evidence, not a blanket re-approval; and a contractual clause requiring the vendor to notify on scope change and on breach.
Track one number that makes the problem visible to leadership: the count of non-human identities holding tenant-wide or global-admin-equivalent permissions, with a target of zero for third parties. Report it monthly alongside the access-review completion rate, since that rate is the leading indicator of whether any of this will hold.