Shared Privileged Access Across Multiple Tenants/Sites

A single secret or a single privileged identity opens multiple client environments or multiple sites: a local admin account with the same password deployed everywhere, a provider’s technical identity present in every client directory, a single password vault where one factor unlocks everything.

This is structural: managed services industrialize administration, and pooling access is the path of least effort — each additional environment reinforces the incentive to reuse what already exists. The boundary between environments exists on paper (distinct clients, distinct contractual scopes) but not on the identity plane: from the point of view of whoever holds the secret, it is a single environment with several names.

The pattern turns an incident into a campaign. The compromise of a single environment — or of a single technician’s workstation — automatically grants access to N environments: the blast radius is no longer proportional to the target, but to the whole portfolio.

Specific consequences for incident response:

• it is impossible to scope the incident to one client as long as the shared secret has not been invalidated everywhere — and proving this to other clients requires evidence that isn’t yet available;
• every environment sharing the secret becomes suspect at once: investigation workload multiplies all at once, on teams sized for one incident at a time;
• emergency rotation of a secret present in N environments takes days, during which the window stays open;
• the question of notifying other clients arises early, with incomplete facts.

The reference question: if this secret leaked tonight, how many environments would be opened? Ask it for every local admin account, every provider technical identity, every vault access.

Concrete checks:

• is there a privileged account whose secret is identical across more than one environment? Verify this without handling authentication material: list the environments where a local admin password randomization mechanism is deployed, and above all what it does not cover — machines outside agent scope, deployment images, accounts created outside procedure. An uncovered scope is presumed to share its secret with the others until proven otherwise;
• list technical identities present in more than one client directory, and their privileges;
• does a technician’s access to environment A prove anything about their right to access B — or are identities, MFA, and logging distinct per environment?
• is the password vault compartmentalized by client, with named access, or is it a single door?

One secret per environment, no exceptions:

• randomize local admin account passwords per machine and per site — this is a solved problem with established tooling, not a major undertaking;
• provider identities distinct per environment, or federation with MFA and logging specific to each environment; the goal is that a compromise does not carry over;
• compartmentalize the vault: partitions per client, named access, MFA, logging of every secret retrieval;
• prepare emergency rotation: a procedure — ideally a tool — capable of invalidating a type of secret across the whole portfolio within hours, tested outside of an incident. The day it’s needed, it sits on the critical path for N clients at once.

Immediately establish the sharing map: which secrets and identities present in the affected environment also exist elsewhere? This is the first question, even before local containment is complete.

Then, in parallel with the investigation:

• any shared secret present in the compromised environment is considered compromised everywhere: launch rotation across all affected environments, starting with the most privileged access;
• check other environments for the indicators observed in the first one: same tools, same accounts, same time windows — an attacker who discovers multi-environment access will use it;
• prepare factual elements for other clients early: what is established, what is ruled out, what is ongoing — the question will be asked, so it’s better to answer it methodically.