Orphaned Service Accounts at Volt Manufacturing
Volt Manufacturing has 1,200 service accounts across three cloud tenants. Thirty-seven have administrator privileges; 22% were not reviewed in the last quarter because their owners left. One service account is shared by three production applications, and no one knows which application uses which permission. The company uses SSO for employees, but service accounts use long-lived API keys stored in a shared password vault. A recent access review found a contractor account with read access to a payroll bucket. The CISO wants least privilege without breaking nightly batch jobs. The identity team proposes disabling all unreviewed accounts at once, but the operations lead warns that this could stop production. There is no reliable inventory linking service accounts to applications or business owners.
1. Prioritize the access risks and propose a 90-day remediation sequence that avoids production outage.
Read the worked answer
Prioritize by blast radius and evidence of misuse, not by account count. First address the contractor account with payroll access and any administrator service account that is orphaned or has long-lived keys. Review cloud audit logs to see whether those identities were used recently, from where, and for what. Do not disable all unreviewed accounts at once; that converts an access risk into an availability incident. In days 1-30, remove the payroll access, rotate exposed keys, and place high-risk accounts in a monitored hold with alerting on use. In days 30-60, map service accounts to applications using authentication logs, configuration files, and application owners, then create per-application identities for the shared account. In days 60-90, move credentials into a secrets manager, replace long-lived keys with short-lived credentials where possible, and enforce just-in-time elevation for administrator roles. Any account still unmapped should be disabled only after a tested dependency check and a rollback plan. Nightly batch jobs should be migrated in waves with explicit success criteria.
2. How should service-account ownership and just-in-time access be designed, and what metrics prove the program is working?
Read the worked answer
Every service account should have a named business owner and a technical custodian recorded in the identity inventory, not just a team distribution list. Ownership should be attested quarterly, and an account without an owner should be treated as high risk and disabled after a dependency check. Just-in-time access should apply to human use of privileged roles, with a request reason, approval, short session duration, and automatic expiry. Machine identities should use short-lived credentials bound to a workload identity rather than shared vault passwords. Break-glass accounts should be separate, monitored, and tested. Useful metrics include percentage of service accounts with a current owner, number and percentage with administrator rights, percentage using long-lived keys, orphaned accounts, time to revoke access after an owner leaves, and number of JIT exceptions. Also track failed dependency checks and batch-job success after migration, because low risk numbers achieved by breaking production are not success.