Build an identity inventory beyond the IAM console
Service identities can exist in cloud IAM, on-premises directories, databases, ERP and CRM platforms, LINE integrations, CI/CD systems, schedulers, and third-party SaaS products. An export from one provider rarely shows where credentials are stored, which workload makes the calls, or what downstream systems depend on the identity. We treat accounts, API keys, certificates, roles, and workload identities as one asset class, then map them to running services, deployment paths, and data flows.
For every identity, the inventory should answer who owns it, why it exists, where it runs, what it can access, how it authenticates, and when reliable activity was last observed. The account name and original creator are clues, not proof of purpose. A practical inventory includes:
- Accountability: the business system, technical owner, and access approver, not only the person who created it.
- Execution context: source hosts, containers, cloud functions, schedules, deployment pipelines, and destination APIs.
- Effective access: direct roles, inherited groups, cross-account trust, and resource-level policies.
- Authentication: long-lived keys, certificates, passwords, managed identities, or workload federation.
- Usage evidence: sign-ins, token issuance, API calls, database sessions, and secret retrieval events.
Distinguish missing evidence from genuine dormancy
No recent login does not necessarily mean an account is unused. Many machine identities operate through token exchange, role assumption, or database credentials and never generate a conventional interactive login. Month-end processing, disaster recovery, certificate renewal, and infrequent batch jobs may also remain quiet for long periods. The review window should cover the relevant business cycle, and engineers must confirm how long each platform retains logs. If the evidence has already expired, classify the result as unknown rather than dormant.
A safe retirement sequence is to identify and notify the owner, observe the workload, block new use or disable credentials, and only then remove roles or delete the identity. Before making changes, capture policies, group memberships, key identifiers, and known dependencies. Define the observation period, alerts, and rollback procedure in advance. When no owner can be found, reducing risky permissions, restricting the source network, or preventing new key creation can lower exposure while the investigation continues.
Do not derive least privilege from logs alone
Activity logs describe what an identity has done, but they do not fully describe what it must be able to do. An unused action might support failover, recovery, or an exceptional deployment path. Least-privilege analysis should therefore compare observed API activity with application code, infrastructure configuration, vendor documentation, failure procedures, and the sensitivity of affected data. Powerful actions such as changing IAM policies, reading every secret, disabling audit controls, or exporting entire datasets require especially clear justification.
Avoid replacing an administrator role with another broad managed role and calling the work complete. Separate identities by function where practical: deployment, runtime execution, backup, and monitoring have different trust requirements. Constrain not only actions but also resources, source environments, conditions, and roles that the account may assume. Production and test environments should not share credentials. Use policy simulation, read-only evaluation, or denied-action analysis when available; otherwise, roll out the narrower policy to a small workload scope and watch authorization failures and operational signals before expanding it.
Turn the audit into an operating control
A one-time cleanup decays quickly because new integrations, urgent fixes, and ownership transfers continue to create machine identities. Provisioning workflows should require an owner, purpose, environment, review or expiry date, and expected permission set. Privileged changes should retain approval and validation evidence. Staff departures, application retirement, major releases, cloud-account restructuring, and anomalous authentication should trigger a fresh review instead of waiting for a calendar-based audit.
Prefer short-lived tokens, managed identities, and workload federation so credentials are not copied into source code, configuration files, or deployment platforms. Where static keys remain necessary, keep them in a central secrets system, rotate them, and monitor retrieval. The meaningful outcome is not a large deletion count. It is an environment where every high-risk service identity has a current owner and explainable purpose, can be disabled safely, and holds permissions aligned with the workload it serves today.