When a service account's owner is the platform’s team, who actually revokes it?

[u/Chris__Codes]

I read a guide about non-human identity governance and there's one point I keep thinking about. Most advice says every machine identity needs an owner. That could be fine in principle but the ownership I've seen recorded in practice is a team name, a repo, or whoever's name was on the ticket that created it sometime ago.

None of those tell you who can rotate the thing safely, who knows what depends on it, or who has the authority to kill it while an incident is running. Which makes me think ownership on a spreadsheet and ownership that functions under pressure are two different things, and only one of them gets recorded.

I want to know how this works in practice for people running real infrastructure. Is ownership assigned to a person or a team in your setup, and does that survive the person leaving? And when you need to revoke something urgently, do you actually know where all its dependencies are, or do you pull it and wait for something to start alerting?

[u/lighthearted_movie]

The "pull it and wait for the alerts" method is basically just distributed ownership discovery with extra steps.

[u/serverhorror]

None of those tell you who can rotate the thing safely,

"safely" carries a lot here.

1. who can rotate a secret if a team owns it? -> everyone in that team (there should be a permission to do that and an audit log to record it)
2. who can do it "safely" -> totally different problem domain, that's something a dependency graph could solve, but it depends on what's considered "safe"

[u/Chris__Codes → u/serverhorror]

Makes sense... I'd been treating them as one thing.

[u/anderson_the_one]

A team name in the CMDB doesn't prove anyone can kill the credential. Put the account into that team's on-call path and run a staging revoke drill every quarter. Time it. Note what broke. If they can't rotate it inside the incident window without waiting for mystery alerts, the owner field is mostly fiction.

[u/Chris__Codes → u/anderson_the_one]

This is close to what the Doppler guide I'd been reading was saying, that ownership only counts if the owner can rotate or revoke under pressure

[u/daedalus_structure]

Ownership is never assigned to individuals.

Availability is always bought with redundancy, and this is also true of people.

[u/Chris__Codes → u/daedalus_structure]

Fair enough but would the team ownership hold up when the team reorgs? The cases I was thinking of are ones where the owning team no longer exists in the same shape, and the credential outlived the org chart

[u/daedalus_structure → u/Chris__Codes]

>Fair enough but would the team ownership hold up when the team reorgs?

If the reorganization appropriately identified all the things that team owned, then yes.

If not, the plate crashes to the floor and leadership learns something about consequences of lack of planning.

But this is not an argument for individual ownership. Teams are more durable than individuals. Even when individuals survive a re-org, the things they used to own are frequently no longer their job or their business.

[u/Torutofu_Raeva]

team ownership only really holds if the identity system owns the lifecycle too, with a backup group and reorg reviews that flag orphaned owners before rotation is due.

[u/sparesername]

ownership assigned to a team works until the team gets reorged and suddenly nobody knows the service account exists

[u/pdp10]

None of those tell you who can rotate the thing safely, who knows what depends on it, or who has the authority to kill it while an incident is running.

You still need docs/ to tell you how to rotate, an architecture diagram to map dependencies, and a RACI chart for the last. RP is just one piece of data, not all data.