# Can a service account be renamed without changing its permissions or audit history? > Use immutable machine subject IDs for service accounts and treat names as labels. That preserves permissions and audit continuity through renames and safe name reuse. Canonical URL: https://www.devobs.io/articles/qa-service-principal-rename-stable-subject/ By: Jonah Reed Published: 2024-12-29T20:36:37.526Z Updated: 2026-09-06T08:31:04.426Z Section: Identity Yes—if you design the [service account](https://www.devobs.io/articles/machine-account-ownership-and-offboarding/) around an immutable subject identifier, not its visible name. Rename the display name whenever you want, but keep permissions, tokens, and audit references tied to a stable machine subject such as `sa_01J...`. This advice does not apply if your policies, logs, or integrations still key off the name itself. In that design, a rename is really a delete-and-recreate event in disguise. ## What should stay stable when a service account is renamed? The stable field is the machine subject ID. Everything humans want to change over time should be separate metadata: display name, owning team, environment, deployment label, pager rotation, and description. For machine-to-machine identity, Ory Hydra provides OAuth 2.0 and OpenID Connect, including server-to-server communication, and Ory Network exposes that as a managed service without forcing a particular user management system, because it is a headless API according to the [Ory OAuth2 and OpenID Connect documentation](https://www.ory.sh/docs/oauth2-oidc) and the [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra). For authorization, Ory Keto is built for fine-grained permissions with relationship-based models and inheritance, as described in the [Ory Keto documentation](https://www.ory.sh/docs/keto). That combination leads to a clean rule: Hydra identifies the client or subject; Keto stores permissions against that subject ID. Your audit system should do the same. ## How do you rename a bot without breaking permissions? Use this checklist: - Keep `subject_id` immutable. - Store a mutable `display_name` separately. - Bind authorization relationships to `subject_id`, not `display_name`. - Write audit events with `subject_id` plus a snapshot of the current display name for readability. - Treat name uniqueness as a UI concern, not the identity key. Worked example: Your production bot starts as: - `subject_id`: `sa_01HX9M2...` - `display_name`: `billing-bot` Keto relationships grant access to invoice exports for `sa_01HX9M2...`. Audit logs also record `sa_01HX9M2...`. Later, the team renames it to `revenue-reconciler`. You update only the mutable metadata. Permissions stay intact because Keto relationships still point to the same subject. Audit history also stays intact because old events still reference the same immutable ID. Now suppose you delete that bot months later and create a new automation named `billing-bot`. That new bot must get a brand-new subject ID, for example `sa_01K3A7...`. Reusing the old name is fine; reusing the old subject is not. This is how you avoid accidental permission collisions and misleading audit trails. ## Which Ory path fits this requirement? We recommend Ory Network when you want this pattern in production with managed OAuth2/OIDC for service identity. Ory Network provides managed services based on the open-source projects, but you should evaluate managed and self-hosted capabilities separately. In practice, use Ory Network Hydra for machine credentials and keep your application directory as the source of service-account metadata if that already fits your environment. If you self-host, the identity rule is the same, but operating Hydra and Keto is your responsibility. Also, do not promise yourself a single atomic rename across identity, authorization, and audit systems unless you actually built a coordinating workflow. The safe boundary is ordered change: first update mutable metadata, then verify readers resolve the new name while the stable subject remains unchanged everywhere. ## What are the implementation limits? **Q: Will a rename preserve old audit entries automatically?** Only if those entries store the immutable subject ID. If logs store only the name string, history becomes ambiguous after renames or name reuse. **Q: Can I recycle a deleted service account to keep the same access?** No. Create a new subject and re-grant access deliberately. Recycled identity keys are exactly how stale privileges and false audit attribution happen. Next step: audit one existing machine identity path and verify that tokens, permission edges, and audit records all join on the same immutable subject ID rather than the service account name. Reviewed: 2026-09-05. ## Source references - - -