A shared account access review is the list of generic logins that more than one person uses. The login might be ops on an appliance, a vendor-portal user, or a database role whose password sits in a note the whole team can open. Auditors ask who owns it and when it goes away. The spreadsheet usually says "the team" and leaves the date blank. That row will not survive a sample.
Rutagon builds the inventory with a named owner and a retire date on every keep, and files it in the GRC platform you already run. The client is the one in the audit. Rutagon builds the evidence pipeline. Individual mailbox access is the sibling problem in shared mailbox access review. A login that no living person still uses is orphaned account cleanup. This article is the login that several people still share.
How a login enters the population
A login enters when more than one person uses it. We do not wait for all of the signals to agree. Two people are enough. The signals we actually see are a password item with several readers, a session trail that shows different people on one username, a vendor portal that has no single workforce id, or an application account that the on-call rotation treats as common property.
The identity provider is not the only source. Shared logins live on appliances, on SaaS tenants that still have a local user, and on tools that never received SSO. AWS does publish a clear preference for human federation and temporary credentials, and for reviewing and removing credentials that are no longer needed, in the IAM security best practices. A generic login fails that test even when the login is not an IAM user. We use the same standard on the systems IAM does not cover.
"The platform team" is not an owner. The named owner is one workforce id. That person is accountable for the retire date and for the replacement. If the named owner leaves, the row reopens until a new person is named. An owner field that points at a mail alias stays open.
Shared account access review fields
Each generic login is one row. The system name is the appliance, the portal, or the application, specific enough that someone can find it. The login name is the generic id, not a person's name. Distinct people is a count with the evidence that produced it: vault readers, session names, or an attested list. The named owner is a workforce id. The retire date is required on any decision other than "remove now." The replacement is either individual accounts or a workload identity. The decision stays empty until a person writes it.
login: generic-name
system: appliance-or-portal
distinct_people: 2
evidence: vault-readers
named_owner: workforce-id
retire_date: required-on-keep
replacement: individual-or-workload
decision: pending
A keep without a retire date does not close. The date is the day the generic login must be gone. After that day, the next export either shows the login removed or reopens the row. Moving the date requires a new decision, recorded, not a quiet edit. We have watched teams slide the date forward every quarter and call the control operated. The history of the date is part of the row.
Break-glass is allowed as a keep only with the same two fields: one owner, one retire date, and a storage path that is not a shared chat. An immortal break-glass login is an ordinary shared account with a dramatic name. The review treats it as one.
Replacement without a second shared secret
The replacement has to be real before the retire date. Individual SSO for each person is the usual replacement for a vendor portal. A workload identity is the usual replacement for a pipeline that was logging in as the generic user. Creating a second generic login called ops2 is not a replacement. We will not file that as progress.
The owner opens the ticket that creates the individual access or the workload identity, then the ticket that disables the generic login. Both ticket ids sit on the row. Disabling first, before the replacement works, is how an outage creates a shadow password. We sequence it: replacement proven, then the generic login disabled, then the secret removed from the shared store. The export after disable is the evidence. A screenshot of a ticket in progress is not disablement.
People who were using the shared login need their own access before the retire date, or they need to be told they are out of scope. Surprise removal is an operational failure. It is still better than leaving the login in place and writing "retired" on a slide. The row records who was granted a replacement so the access review of those new accounts has a source. Otherwise the shared login dies and five standing personal accounts appear with no request.
What the sample looks like
The auditor's sample is a login, an owner, a date, and proof the login is gone or is still inside its retire window with a reason. We file that pack in the GRC you already run. The ticket id comes back onto the export. Systems we cannot query are still rows: someone attests the distinct people, and the owner and the retire date are still mandatory. Attestation without those two fields stays open. We do not upgrade an attestation into a technical fact.
This work sits with security automation for access reviews. We are not introducing a second identity provider for the appliance that will never speak one. We are making the generic login visible, owned, and dated. Rutagon's own pipelines do not use a shared personal login. Jobs take a short-lived identity. Where a device still has a local admin password, it has a named owner and a retire date, same as a client row.
The production lesson is the blank date. Teams will name an owner easily, because a manager will volunteer. They will leave the retire date empty because a date creates work. The collector treats the empty date as an open row. That single rule is what makes the review different from a contact list of generic logins.
Frequently Asked Questions
What counts as a shared account?
A login that more than one person uses, on a portal, an appliance, or an application. Two people are enough to enter the population. A shared mailbox has its own pack, and a login with nobody left on it is an orphan record.
Can the owner be a team name?
The named owner is one workforce id. A mail alias or a team label leaves the row open. If that person leaves, the row stays open until another workforce id is recorded.
What makes a keep decision valid?
A retire date and a replacement: individual access or a workload identity. The date is the day the generic login must be gone. After that day the next export reopens the row if the login still works. Moving the date is a new decision with history kept.
How do you retire the login safely?
Prove the replacement first, then disable the generic login, then remove the secret from the shared store. Both tickets are stored on the row. A second generic login is not a replacement. The export after disable is the evidence the sample can follow.
Where is the pack filed?
In the GRC you already run, mapped to the access-review control you already named. Systems we cannot query still need an owner and a retire date. Attestation does not erase those fields. The ticket id on the pack is how the sample is retrieved.
See what an Access & Credential Governance Diagnostic finds in your environment. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.