# Split a shared service account without breaking rare jobs

Move workloads to individual identities using an operation inventory and staged verification. Recent traffic alone will miss some required permissions.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Map every consumer of the shared identity

Inventory services, scheduled jobs, deployment tools and manual procedures that use the credential. Include inactive schedules and disaster-recovery tasks.

Use logs to supplement the inventory, not replace it. A quarterly export will not appear in a short observation window, and an unexercised recovery path may still be required.

Assign an owner to each consumer before creating replacement roles. Otherwise the migration can produce several narrower identities that nobody maintains.

## Create purpose-specific replacements

Define trust and permissions for each workload according to its operations. Prefer the platform's supported temporary identity mechanism where it fits.

Keep runtime and deployment authority separate. The shared account may have combined them historically, but the replacement need not preserve that unnecessary coupling.

Test each new identity against synthetic normal and recovery workflows, including deliberate denials outside its scope.

## Move consumers in controlled groups

Deploy one workload or a bounded group with the new identity and confirm the actual principal in runtime evidence. Watch for unexpected denials and diagnose them against the operation matrix.

Do not leave a silent fallback to the old shared key, because it can make the migration appear successful while the broad credential still performs the work.

For a synthetic monthly import, trigger its supported test path before declaring migration complete. Waiting for the next calendar run may leave a critical gap undiscovered.

## Retire the old access with evidence

Reconcile all consumers and remove the old credential through the provider's supported revocation process. Check residual trust relationships, cached credentials and deployment configuration.

Define rollback carefully. If the old key is revoked, restoring an old application configuration will not restore access. Keep a controlled recovery route that does not depend on an indefinitely active shared secret.

After retirement, verify both normal service operation and denial of the old identity. Update ownership and operating notes so future services do not copy the obsolete shared-account pattern from an old example.

## Sources

- [AWS: IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [AWS: policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)