The audit log says admin. Which human was that?

Six people know the password to the account that exported the customer table. The log is complete, timestamped, and names a credential rather than a person. Deleting shared accounts is not achievable everywhere, so the achievable goal is different: let the credential stay shared and make the action personal.

The incident review starts at nine on a Tuesday morning and everyone in the room already knows how it ends.

At 02:47 the previous night, someone ran an export against the production customer table. Four hundred thousand rows, written to a bucket that had been created eleven minutes earlier. The logging was excellent. There is a timestamp accurate to the millisecond, the source address, the query text, the byte count, the destination, and the account that did it.

The account is svc-deploy.

The security lead asks the only question that matters, which is who was holding that credential at 02:47, and the room goes quiet in a very particular way. Not the quiet of people hiding something. The quiet of six competent adults simultaneously realising that the answer is unknowable from the evidence, and that the next four weeks of their lives will be spent on interviews, calendar reconstruction, VPN logs, and the awkward business of asking colleagues to account for their whereabouts in the middle of the night.

Three of them had legitimate reasons to be in that system. One was on call. One was debugging a migration. One had gone to bed at eleven and can prove nothing at all, which is the ordinary condition of a person who was asleep. The credential is in the vault, checked out four days earlier for a maintenance window and never checked back in, because nobody checks things back in.

The investigation will not close. It will be marked inconclusive, a control will be added, and the same review will happen in eighteen months with different names.

Why does every organisation end up with shared credentials?

Before proposing anything, it is worth being honest about why this happens, because the reader has almost certainly done it and had good reasons at the time. The literature on this topic has an unfortunate tendency to treat shared credentials as a hygiene failure committed by careless people. It is not. It is a rational response to a set of constraints that nobody in the security team controls.

Per seat licensing makes individual accounts a budget line

A great deal of enterprise software is priced per named user. When a team of eight needs occasional access to a tool that costs a meaningful amount per seat per month, the finance conversation is short and the outcome is one shared login. This is not a security decision, it is a procurement decision, and it is made by people who are optimising a different variable. Telling that team to buy eight seats is advice, not a control, and it will be ignored for entirely understandable reasons.

Some systems only support one administrator

Legacy appliances, older industrial control software, embedded management interfaces, certain database engines in their default configuration, and a surprising amount of network hardware support exactly one administrative identity. There is no user table to add anyone to. The vendor shipped it that way in 2011 and the product reached end of support without ever gaining multi user administration. You cannot create named accounts on a system that has no concept of them.

Clinical and retail environments have real speed constraints

A nurse moving between four rooms on a ward, or a cashier serving a queue at a supermarket, cannot complete an individual authentication ceremony at every interaction without the workflow collapsing. This has been studied extensively in healthcare informatics, and the reliable finding is that when authentication friction exceeds what the workflow can absorb, staff work around it. They prop the session open, they share the badge, they write the code on the monitor. The workaround is not indiscipline, it is the predictable result of a control that was designed without reference to the work.

Break glass accounts are supposed to be shared

Every mature organisation maintains an emergency access path that bypasses the normal identity provider, precisely so that a failure of the identity provider does not lock everybody out of everything. That account is deliberately not federated, deliberately not dependent on the single sign on that might be the thing that is broken, and deliberately available to more than one person, because the whole point is that it works at three in the morning when one specific engineer is unreachable. Break glass is a shared credential by design and by good design.

Managed service providers operate at the boundary

A managed service provider administering dozens of client tenants faces the same problem multiplied. The common pattern is a provider held administrative identity inside each client environment. The provider is one legal entity from the client's perspective, but the humans behind that identity are a rotating team of technicians. CISA has published guidance on the risks flowing from this arrangement, and its structural point is that trust granted to a provider is trust granted to everyone who can act as that provider.

Add these together and the shared credential is not an anomaly. It is the equilibrium. Any proposal that begins by assuming it can be removed will be politely received and quietly shelved.

What does an audit log actually prove?

Here is the uncomfortable observation at the centre of this problem. Most organisations believe their logging tells them who did things. It does not. It tells them which credential did things, and then a human reader silently performs a substitution, treating the credential name as a person's name because in the common case one person holds one credential.

That substitution is a habit, not a fact, and it fails precisely when it matters. It fails for shared administrative accounts. It fails for service accounts. It fails for anything an automation runs. It fails for managed service provider identities. It fails for break glass. And it fails silently, because the log looks exactly as complete in the failure case as in the working case. There is no field that says "the attribution in this record is unreliable".

A useful way to hold this in your head: a log entry is a receipt from a shop that records which credit card was used. If one person holds that card, the receipt tells you who bought the sandwich. If the card lives in a shared drawer in the office kitchen, the receipt tells you a sandwich was bought. The receipt has not degraded. It is exactly as accurate as it ever was. What changed is the relationship between the instrument and the person, and no amount of improving the receipt recovers the missing information.

This matters because logging is the control that everything else leans on: incident response, insurance claims, regulatory attestations, internal disciplinary processes. When the attribution underneath is a habit rather than a fact, all of them inherit the weakness without anyone noticing, because the artifact they are reading looks authoritative.

We named this failure mode in the Identity Failure Map. It is the attribution branch of the same structural problem that produces session theft: systems record which principal performed an operation, and treat that as equivalent to recording which human intended it. Those are different claims and only one of them is supported by the evidence.

Why does privileged access management not solve this?

The standard answer to shared credentials is a privileged access management platform, and privileged access management is genuinely valuable. It rotates the credential so it is not a static secret on a wiki. It brokers access so the raw password never reaches the operator. It records sessions so there is video of what happened. It enforces approval workflows for elevation. These are real controls and an organisation with them is meaningfully better off than one without.

But look carefully at what the attribution actually binds to, because this is the crux and it is usually skated over.

A privileged access management system attributes a checkout. Someone authenticated to the vault, requested the credential, and was granted a session at a particular time. Everything that happens after that point inside the session is attributed to the session, and the session is attributed to the checkout. That chain is only as strong as the assumption that the person who checked out the credential is the person at the keyboard for the entire duration of the session, which is an assumption and not a proof.

Consider the ordinary ways that assumption breaks, none of which involve malice. A session is checked out for a maintenance window and stays open for four days, as in the scene that opened this piece. An engineer starts a session, gets pulled into an incident, and a colleague finishes the work on the same screen. Two people pair on a migration and only one checked out the credential. A session persists across a shift change on a shared operations workstation. In each case the vault log is accurate and the attribution is wrong.

Session recording is often offered as the answer to this, and it does help an investigator reconstruct events. But notice what it actually is: a video attributed to a checkout. It shows you the commands. It does not show you the face, and if it did, you would have built a surveillance system in order to answer an accountability question, which is a poor trade and one we argue against in the piece on monitoring versus attestation. Reviewing recordings also does not scale. Nobody watches them until after something has gone wrong, which means they are forensic rather than preventive.

Just in time elevation has the same shape. It reduces the window during which the authority exists, which is a genuine improvement to blast radius, and it attributes the elevation request. Everything inside the elevated window inherits that single attribution event.

None of this criticises the products. It observes what the category is built to do. Privileged access management controls and records access to credentials. Attribution of individual actions to individual humans is a different problem, and no amount of improving credential brokering solves it, because the information is not lost in the brokering, it is lost at the moment the action executes.

What do the regulators actually require?

This is where the problem stops being an engineering irritation and starts being expensive, because several regulatory frameworks require exactly the thing that shared credentials cannot deliver.

In the payment card world, requirement 8 of the PCI Data Security Standard has for many years required that users with access to cardholder data be identified individually, with the reasoning stated plainly in the standard itself: individual identification is what makes it possible to hold a person accountable for their actions. Version 4 of the standard extended the treatment of shared, group, and application or system accounts with additional provisions. Assessors have been asking about shared administrative accounts for as long as the standard has existed, and a shared credential with several holders is a finding that has to be managed with compensating controls rather than waved away. The precise clause numbering has shifted across versions, so the practical move is to read the current standard text from the PCI Security Standards Council document library rather than trusting any blog post, including this one, on which sub requirement applies to your situation.

In pharmaceutical and medical device manufacturing, the governing idea is ALCOA, the requirement that records be Attributable, Legible, Contemporaneous, Original, and Accurate. Attributable is first for a reason. The United States regulation on electronic records and electronic signatures is unusually direct on the point: 21 CFR 11.100(a) states that each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else. There is no reading of that sentence under which a shared login satisfies it. Shared credentials in regulated manufacturing environments are a recurring theme in inspection findings, and the remediation is expensive because it usually involves systems that were not designed for individual accounts.

In the federal control catalogue, NIST Special Publication 800-53 addresses this from two directions. The account management controls constrain the use of shared and group accounts and require that their use be justified and reviewed. The audit record content control requires that audit records establish the identity of any individuals associated with the event. That word, individuals, is doing the same work as attributable in ALCOA and unique in Part 11. The standards keep asking for the same thing.

The pattern across all three is worth stating explicitly, because it reframes the whole problem. Regulators do not actually require that you avoid shared credentials. They require that you can attribute actions to individuals. Eliminating shared credentials is one way to achieve that, and it is the way everyone assumes because it is the only way anyone has offered. It is not the only way.

What if the credential stays shared and the action becomes personal?

Here is the reframe that unlocks this problem, and it is small enough to state in one sentence: separate the convenience of access from the accountability for effect.

You need the shared credential because of licensing, legacy systems, workflow speed, and emergency availability. All of those constraints attach to access. None of them attach to the handful of consequential actions that an investigator or an auditor will actually care about. A nurse needs to reach the chart in two seconds. A nurse does not need to administer a controlled substance in two seconds without any record of who administered it. Those are different operations with different time budgets and different consequences, and the mistake is treating them as one thing because they happen behind one login.

So: keep the shared session. At the moment a consequential action is invoked, require a fresh signature from the acting human, produced on their own enrolled device, over the specific details of that action. The shared credential still executes the command. The receipt names the person.

The analogy that makes this click for most people is the controlled drugs cabinet on a hospital ward. The ward has one key, or one door code, and everybody who works there can open it, because a locked cabinet nobody can open in an emergency is worse than useless. Access is shared deliberately. But when something is taken out of that cabinet, a named person signs the register, and a second named person witnesses it. Nobody in healthcare thinks this is a contradiction. The door is shared. The withdrawal is personal. Hospitals worked this out a very long time ago and the software industry has somehow not imported the idea.

The clinical workstation

A shared workstation stays logged in to the electronic health record throughout the shift, because the alternative has been tried repeatedly and does not survive contact with clinical work. Reading a chart, checking a result, and looking up a schedule all happen under the shared session with no additional ceremony. Ordering a controlled substance, overriding a clinical decision support warning, amending a signed note, or exporting a patient list requires a signature from the clinician's own device. Those four actions are the ones that appear in adverse event reviews and regulatory inspections. Everything else is reading.

The retail terminal

The point of sale runs under a store credential because a queue does not wait. Ringing items, taking payment, and printing receipts are ordinary and ungated. Voiding a completed transaction, opening the drawer with no sale, applying a manual discount above a threshold, and processing a refund to a card that was not used for the purchase are the actions that appear in every retail shrinkage investigation. Those four get a signature from the supervisor's device, which is a two second interaction on a phone already in their pocket, and which replaces the manager's key or the shared override code that currently exists in every store and is known by everybody.

The on call rotation

Break glass stays exactly as it is, available to the whole on call rotation, unfederated, and functional when the identity provider is not. What changes is that using it to perform a destructive or irreversible operation produces a signature from whoever is actually holding the pager. The emergency path stays fast. It stops being anonymous. This is the same design principle we describe for deployment approvals and for destructive database operations: the emergency route should be fast and loud rather than slow and quiet.

Notice how short each list in the third column is. That is the practical heart of the approach. You are not gating everything, which would be intolerable and routed around within a week. You are identifying the few operations whose consequences are severe or irreversible, and requiring that those carry a name.

What does the signature actually cover?

Vagueness here is where these schemes go wrong, so let us be concrete about the bytes.

The thing being signed is not "I am logged in" and not "I approve", both of which are useless after the fact. It is a canonical description of this specific action, including which shared credential is executing it. That last field is what makes the receipt do its job, because it is the explicit bridge between the credential the system logged and the human the investigator needs.

{
  "action": "db.export",
  "target": "prod.customers",
  "row_estimate": 412883,
  "destination": "s3://exports-eu/2026-09-20-cust/",
  "executing_credential": "svc-deploy",
  "system": "warehouse-prod",
  "ticket": "INC-40912",
  "requested_at": "2026-09-20T02:47:11Z"
}

That object is canonicalised, hashed, and the hash becomes the challenge for a WebAuthn assertion on the acting person's enrolled device. What comes back is a signature over that exact content, bound to a key in that person's hardware that cannot be copied out of it. The application stores the assertion next to the log line.

# at the sensitive action, not at login
payload = canonical(action_details)          # deterministic bytes
digest  = sha256(payload)
receipt = manav.sign(digest)                 # human taps their own device

if not receipt.valid:
    abort("unsigned privileged action")      # fail loud, fail closed

audit.write(
    event      = action_details,
    credential = "svc-deploy",               # what executed
    actor      = receipt.subject,            # who authorised
    receipt    = receipt.id                  # verifiable offline
)

Two properties of that receipt are worth dwelling on because they are what distinguish it from another log field.

First, it is verifiable by someone who does not trust you. An Ed25519 signature checks against a published key with no call back to any service, which means an auditor, an insurer, a regulator, or the opposing party in a dispute can confirm it independently. A log line, by contrast, is an assertion by the organisation about its own conduct, which is exactly the sort of evidence that carries the least weight when it matters most. We go through this distinction properly in the piece on offline verification.

Second, it survives the system. Log retention is finite, systems get decommissioned, vendors go out of business. A signature over a canonical payload stays checkable for as long as the public key is published, decoupling your evidence from the lifetime of the platform that generated it.

What does this give an auditor that a log does not?

Put the artifacts side by side and the difference becomes obvious.

For a payment card assessment, the conversation changes shape. Instead of arguing that a shared administrative account is acceptable because of compensating controls that are difficult to evidence, you can show that every operation within the assessment scope carries an individual attribution that does not depend on the honesty of the log. For a regulated manufacturing inspection, the attributable element of ALCOA has an artifact behind it rather than a policy statement. For an insurance claim, you can demonstrate which human authorised the action that caused the loss, which is frequently the pivotal question and frequently unanswerable.

For an incident like the one that opened this piece, the four week investigation becomes a database query. Either there is a receipt naming a person, or there is not, and the absence is itself informative: an export that ran with no receipt attached is either a control bypass or an automation that needs to be brought into the delegation model, and both of those are findable in an afternoon.

What about actions that no human performed?

This objection deserves a straight answer rather than a deflection, because a great deal of what runs under service accounts is genuinely automated and attributing it to a human would be a lie.

The honest model here is delegation rather than signature. A human authorises a scoped, time bound, revocable grant that permits an automation to perform a defined class of operations, and each automated action references that grant. The receipt then says something true and useful: this operation was performed by an automation, under authority granted by this named person, on this date, with this scope, expiring at this time. That is a different claim from "Priya ran this query at 02:47" and it should look different in the log, because pretending a nightly job was a human decision corrupts the record in the opposite direction.

This is the same structure we describe in the authority graph and in delegation chain depth, and it becomes more important as the ratio of non human to human identities climbs, which by most accounts it has been doing sharply for several years. The point is not to put a human name on machine activity. The point is that every piece of machine activity should trace back to a human who authorised that class of activity, and that trace should be checkable.

Honest limits

Several things this does not do, stated plainly, because a control sold beyond its evidence is worse than no control.

• It attributes gated actions only. Anything you did not classify as consequential remains attributed to the credential. The classification exercise is the real work, and getting it wrong in either direction has a cost: too narrow and the important thing is not covered, too broad and staff route around it.
• A signature proves authorisation, not judgment. Someone who taps through without reading has still signed. This gives you accountability, which is genuinely valuable, and it does not give you correctness. No cryptographic control has ever made a decision good.
• Duress and device handover defeat it. A person can be coerced into signing, or can simply hand their unlocked phone to a colleague. The receipt then names them accurately and misleadingly at the same time. This is the same limit that applies to a physical signature on a register and it is not solvable by technology.
• It does not retrofit history. Every action taken before you deployed this remains as unattributable as it was. There is no way to reconstruct who held a shared credential last year.
• Enrollment is the trust bottleneck. The receipt is only as meaningful as the process that bound a key to a human. If enrollment is sloppy, everything downstream inherits that.
• It adds latency to the gated actions. A device tap is a few seconds. On operations performed hundreds of times a day, that is unacceptable, which is another reason the gated set must stay small.

What to do this week

1. Inventory the shared credentials you actually have, including break glass, service accounts, kiosk logins, managed service provider identities, and the shared SaaS seats that finance bought. Most organisations discover the list is longer than the one in their asset register.
2. For each one, write down why it is shared. If the reason is licensing or laziness, that is fixable with money or a sprint. If it is legacy architecture, emergency availability, or workflow speed, accept it and move to attribution.
3. List the consequential actions available under each credential. Aim for three to six per credential. The test is irreversibility and blast radius, not sensitivity in the abstract.
4. Check your last incident review for the phrase "we could not determine". That sentence is a map of where your attribution is missing, and it is more reliable than a theoretical exercise because it reflects what actually went wrong.
5. Ask your assessor or inspector directly whether an individual per action attestation would address the shared account finding. In our experience this conversation goes better than teams expect, because the assessor is trying to satisfy an attribution requirement rather than an account structure requirement.
6. Pick one credential and one action and instrument it. Break glass is usually the best starting point, because the volume is low, the consequences are high, and nobody argues that emergency access should be anonymous.
7. Decide what happens when a gated action arrives with no receipt. Fail closed is the right default for irreversible operations. Fail open with a loud alert is defensible for availability critical paths. Failing silently is not a position, it is an oversight.
8. Bring automations into the delegation model rather than leaving them as unattributed service account activity, so a missing receipt becomes genuinely anomalous rather than routine.

If you want to see the shape of this before building anything, the privileged action gating demo walks through a shared administrative operation that requires a personal signature, and the developer documentation covers the signing and verification calls.

Frequently asked questions

Are shared admin accounts allowed under PCI DSS? Requirement 8 of the PCI Data Security Standard requires that users with access to cardholder data be identified individually, precisely so that actions can be traced to a person. Shared administrative accounts therefore attract assessor attention and generally need compensating controls. Read the current standard text from the PCI Security Standards Council rather than relying on secondary sources, since clause numbering has changed between versions.

How do you attribute actions taken with a shared admin account? Require the person performing a consequential action to sign that specific action from their own enrolled device. The shared credential still executes the command, and the receipt names the human. Attribution then holds regardless of who holds the password, and the receipt verifies offline against a published key rather than resting on the integrity of your own log.

Does privileged access management already solve this? Not quite. It attributes a credential checkout and records the session that follows. Everything inside that session inherits one attribution event, which breaks when a session outlives the maintenance window, changes hands during an incident, or persists across a shift change. It is a valuable control for access, and attribution of individual actions is a different problem.

Do we have to eliminate shared accounts? No, and for root, break glass, kiosks, and legacy systems that support a single administrator you cannot. Regulators generally require that actions be attributable to individuals rather than that accounts be individual. Eliminating shared credentials is one route to that outcome and per action attribution is another, which is achievable where the first is not.

How do you attribute automated actions under service accounts? You do not attribute them to a human directly, because that would be false. Instead a named human authorises a scoped, time bound, revocable delegation covering a class of operations, and each automated action references that grant. The record then states accurately that an automation acted under authority granted by a specific person within a specific scope.

Sources

1. PCI Security Standards Council, Document Library. https://www.pcisecuritystandards.org/document_library/
2. US Code of Federal Regulations, 21 CFR Part 11, Electronic Records and Electronic Signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
3. US Food and Drug Administration, guidance documents including data integrity for drug CGMP. https://www.fda.gov/regulatory-information/search-fda-guidance-documents
4. NIST Special Publication 800-53 Revision 5, Security and Privacy Controls. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA, Protecting Against Cyber Threats to Managed Service Providers and their Customers (AA22-131A). https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a
6. Verizon, Data Breach Investigations Report series, on credential abuse. https://www.verizon.com/business/resources/reports/dbir/
7. ISO/IEC 27001, Information security management systems. https://www.iso.org/standard/27001

The door can be shared. The signature cannot.