Four companies deep, someone has your production credentials

Every enterprise runs due diligence on the supplier it signs. Almost none can see the three organisations underneath it, and the human who actually holds privileged access sits at the bottom of that stack. This is a walk through why the contractor chain exists, why assurance degrades at every link in it, why privileged access management does not close the gap, and what an identity that travels with the person rather than with the employer would change.

One firewall change, three companies, no name

Start in the incident review room of a mid sized bank, six weeks after the thing that happened. The finding is narrow and specific: at 02:14 on a Sunday, a rule on an edge firewall was modified in a way that widened access to a segment it should not have reached, and that rule stayed in place for nine days before a routine configuration comparison caught it.

The bank's logs are excellent. They show the change, the before and after configuration, the source address, and the account that made it. The account belongs to the managed service provider that runs the bank's network operations under a contract signed three years ago.

So the bank asks the managed service provider a simple question: who did this?

The provider's answer takes eleven days and arrives in pieces. The work came from a ticket in their system, raised by their scheduling process, assigned to a regional partner firm that handles overnight coverage in that time zone. The regional partner says the ticket was picked up by a technician sourced through a staffing agency they use for weekend rotations. The staffing agency confirms it placed someone that weekend and provides a name. Nobody at the bank has ever heard that name, nobody at the bank has ever verified that person's identity, and by the time the question is asked, that person is no longer on the account.

Four organisations were involved in one firewall change. Exactly one of them, the bank, carried the regulatory obligation. Exactly one of them, the technician, touched the keyboard. Those were not the same organisation, and there is no artifact anywhere in the chain that binds the action to the human.

Why does the contractor chain exist at all?

It is tempting to read the story above as negligence. It is not, and starting from that assumption will lead you to the wrong control.

The chain exists because it is economically rational at every single link. The bank does not want to employ network engineers in three time zones to cover a Sunday night, so it buys managed service. The managed service provider does not want to employ engineers in every region it sells into, so it partners regionally. The regional partner does not want salaried staff idle between incidents, so it uses an agency for surge and overnight coverage. The agency does not want the fixed cost of specialists in every technology, so it engages individuals, some of whom operate through their own limited companies for entirely ordinary tax and liability reasons.

At no point does anyone make a bad decision. Each layer is a sensible response to the problem that specialised technical skill is expensive, unevenly distributed geographically, and needed in bursts. This is how the global market for technical labour actually clears, and an enterprise that refused to participate would pay considerably more for worse coverage.

The problem is not that the chain exists. The problem is that identity was never designed to travel along it.

What breaks at each link?

Here is the mechanism, and it is worth going slowly because the shape of the degradation is what makes the problem hard.

At each boundary in the chain, one organisation tells the next organisation who somebody is. The bank does not verify the technician. It verifies the managed service provider, once, at contract signature, through a due diligence process that examines the provider as a company: its certifications, its policies, its audit reports, its insurance. That process says nothing about individuals, and it is not designed to.

The managed service provider then makes an assertion to the bank, implicitly, every time one of its people touches the bank's systems: this is our authorised technician. The bank accepts that assertion because it has a contract. The regional partner makes the same assertion to the managed service provider. The staffing agency makes it to the regional partner. The individual makes it to the agency.

Every one of those is a claim, not a proof. Nobody in the chain is lying, in the normal case. But a claim passed along four times is a rumour with paperwork.

Assurance decays multiplicatively while contracts do not

Suppose, purely for illustration, that each handoff preserves ninety percent of your confidence about who the person is. That number is invented for the sake of the arithmetic and nobody has measured it. Four handoffs later you are at roughly sixty six percent, and you did not notice the decline because at no point did anything fail. Each individual link looked fine.

Meanwhile the enterprise's contractual protections do not decay gracefully, they stop. The bank has an agreement with the managed service provider. It has no privity with the regional partner, the agency, or the individual. Flow down clauses attempt to bridge this by requiring each party to impose equivalent terms downstream, and they are worth having, but a flow down clause is a promise about a promise. The bank cannot audit a company it has no relationship with, and in practice most enterprises cannot even enumerate who those companies are.

So you get the characteristic shape of this risk: assurance falls with depth, obligation stays at the top, and visibility is zero below the first link.

The evidence that this matters

Third party involvement in breaches has become one of the most consistently reported findings in the field. Verizon's 2025 Data Breach Investigations Report described third party involvement roughly doubling year over year, to around thirty percent of the breaches it analysed. Treat the precise figure directionally, as the report's own methodology notes discuss what counts as third party involvement and the definition materially affects the number, but the direction has been consistent across several years and several publishers.

The structural reason managed service providers in particular are attractive targets is simple arithmetic: a technician account at a provider serving four hundred clients is a key to four hundred networks. The 2021 compromise of Kaseya's remote monitoring and management tooling, which propagated ransomware through providers into their clients, remains the clearest public demonstration that the provider is a distribution channel as well as a supplier.

And there is a deliberate version of this. The documented remote worker infiltration schemes, covered in the laptop farm piece, work precisely by exploiting the opacity of hiring and contracting chains, where the entity in the contract and the person at the keyboard are different by design rather than by accident. A chain that cannot tell you who is working is a chain that an adversary can enter without breaking anything.

Why doesn't privileged access management solve this?

This is the fair objection, and enterprises reading this have usually spent a great deal of money on exactly the products that appear to address it. Privileged access management from vendors such as CyberArk, Delinea and BeyondTrust does real and valuable work. It vaults credentials so they are not pasted in a runbook. It brokers sessions so the credential is never handed to the endpoint. It records sessions for later review. It rotates secrets. None of that is theatre.

But look carefully at what the resulting audit record actually asserts. It says: at 02:14, a checkout occurred against the vault, authenticated as a particular account, and a session was brokered to the firewall. If that account is a shared provider administrator account, which in operational reality it very often is, the record identifies a company and a role. If the account is individual to a technician, the record identifies a directory entry in the provider's tenant, which the provider created, manages, and can reassign, and which the client cannot independently verify corresponds to any particular human.

Session recording is sometimes offered as the answer to attribution. It is not attribution, it is observation. A video of hands on a keyboard tells you what was done, not who did it, unless someone can match the session to a person by other means. It is also, for what it is worth, the surveillance shaped answer, with the costs discussed in the piece on proof versus surveillance.

Access reviews have the same limitation as re-attestation everywhere else in this series. They run quarterly or annually and confirm that an account should exist. They do not ask whether the human behind it this week is the human behind it last quarter. That is the identity continuity failure, appearing here in a supply chain rather than an employment context.

A newer category of product has begun to address the technician verification question directly, typically by confirming a phone number or a code between the technician and the end user before a support session. This is a genuine improvement over nothing, particularly against help desk social engineering. It verifies a contact channel rather than an enrolled human, and it operates at one hop, between the provider and the client, which is exactly the hop that was never the problem.

What can the enterprise actually verify at each depth?

Read that table as an attribution gap rather than a list of failures. Every row below the first is a place where the enterprise is relying on somebody else's assertion, and the rows compound.

What do regulators now expect?

The supervisory position has moved considerably, and it has moved toward named accountability rather than toward more paperwork about suppliers.

In the European Union, the Digital Operational Resilience Act has applied since 17 January 2025, and it obliges financial entities to maintain a register of information about contractual arrangements with information and communication technology third party providers, including arrangements involving subcontracting of critical or important functions. The significant word is subcontracting. The regime explicitly contemplates that the chain has depth and expects the regulated entity to know about it, which is a direct response to the visibility gap described above.

In New York, the amendments to the Department of Financial Services cybersecurity regulation, Part 500, tightened requirements around third party service provider policies and access controls with obligations phasing in through 2025. The direction is the same: the regulated entity remains accountable for access granted to outsiders, and is expected to be able to describe and control it.

Neither regime issues the primitive that would make compliance straightforward. They create the obligation and leave the mechanism to the market, which is the normal and reasonable division of labour. But it does mean an enterprise can now be asked a question by a supervisor that it structurally cannot answer, which tends to concentrate attention.

What would identity that travels with the human look like?

The alternative is to stop treating identity as something each organisation asserts to the next, and start treating it as something the individual carries.

The technician enrols once, to a device they control, producing a key that is theirs rather than their current employer's. The enterprise then issues a scoped delegation to the managed service provider. The provider sub delegates to the regional partner, narrowing the scope. The partner sub delegates to the technician, narrowing again. Every privileged action the technician performs is signed on their enrolled device under that chain, and the enterprise verifies the whole chain itself, offline, without asking anyone.

The chain, concretely

{
  "issuer":       "org:northgate-bank",
  "subject":      "org:meridian-msp",
  "scope": {
    "actions":    ["firewall.rule.change", "firewall.config.read"],
    "systems":    ["edge-fw-lon-*"]
  },
  "constraints": {
    "maxChainDepth": 3,
    "window":        "change-window-only"
  },
  "notBefore":    "2026-09-01T00:00:00Z",
  "notAfter":     "2026-12-01T00:00:00Z",
  "revocationId": "rv:8c41d0e7",
  "delegateKey":  "ed25519:9f2b41c0e7d3a58b"
}

The provider signs a second object delegating a subset of that scope to the regional partner, with depth now at two. The partner signs a third to the technician, at depth three. Each link can narrow the scope and none can widen it, which is the property that makes the chain safe to pass along: authority can only shrink as it travels. The mechanics are covered properly in the delegation chain post, so this piece will not re-derive them.

What the firewall does at 02:14 on a Sunday

def authorise_privileged_action(action, receipt, chain):
    if not verify_signature(receipt, chain.leaf.delegateKey):
        return deny("action not signed by the delegated key")
    if sha256(canonical(action)) != receipt.challenge:
        return deny("signature does not cover this action")
    root = walk(chain)                  # verifies each hop offline
    if root.issuer != "org:northgate-bank":
        return deny("chain does not root in us")
    if not monotonic_narrowing(chain):
        return deny("a hop widened its scope")
    if len(chain) > chain[0].constraints.maxChainDepth:
        return deny("chain too deep")
    if any_revoked(chain) or expired(chain):
        return deny("revoked or expired")
    log(action, signer=receipt.signer, chain=chain.ids)
    return allow(action)

Six weeks later, when somebody asks who changed the firewall rule, the answer is a name, a key, and a verifiable path from that key back to the bank's own delegation. Not eleven days of email between four companies.

There is a second, quieter benefit. Revoking the bank's delegation to the provider invalidates everything beneath it in one operation, because the sub delegations derive their authority from it. That is the property ordinary credential sprawl lacks, and it is discussed at greater length in the revocation post. And because the receipts belong to the technician, they accumulate into a portable record of verified privileged work, which is worth something to a contractor whose employer changes every eighteen months.

Why is this the same shape as agent delegation?

Something worth noticing, because it suggests the primitive is more general than any one use case.

The structure just described, a principal issuing scoped authority, intermediaries narrowing and passing it along, a bounded depth, an actor signing individual actions under it, and a verifier walking the chain back to the root, is exactly the structure required when an AI agent delegates work to another agent. It is the same object, the same verification walk, and the same failure modes.

That is not a coincidence. Both problems are instances of one question: how does authority travel across boundaries without becoming a rumour. Organisations have been answering that question with contracts, and contracts do not verify. The authority graph is the same answer applied to software agents, and identity fan-out describes what happens when the tree gets wide. A contractor chain is simply a delegation tree whose nodes happen to be human beings and limited companies.

What are the honest limits?

• This requires cooperation down the chain, and your leverage falls with depth. A bank can require its provider to adopt something. Whether that requirement survives to the staffing agency depends on commercial pressure that weakens at every hop. Realistically this arrives through the largest clients in regulated sectors first, and spreads because providers do not want to run different processes per client.
• The technician has to enrol, and their employer may want to control that. A provider that enrols technicians under its own control recreates the original problem in a new format. The design only works if the key belongs to the individual, which is a commercial and cultural change as much as a technical one.
• Depth limits are a policy choice, not a safety proof. Setting maximum depth to three does not make three hops safe. It makes the fourth hop visible, which is different and less than it sounds.
• It does not address what happens on the technician's own machine. A compromised endpoint at depth four is still a compromised endpoint, and a signature proves who authorised an action, not that their device was clean.
• Emergency access will route around it if you let it. Every organisation has a two in the morning path, and if the signing flow is slower than the incident, people will find the shared credential. That is a design constraint, not an objection, and it is the same lesson as break glass access.
• None of this improves conditions at the far end of the chain. Subcontracting depth is often a mechanism for moving labour cost and employment risk away from the client, and making the individual visible for attribution purposes does nothing about their pay, their security of engagement, or their bargaining position. It is worth naming that plainly rather than pretending a security control is a labour reform. If anything, a portable record of verified work is the one part of this that might modestly benefit the person at the bottom.
• Manav has shipped no privileged access management connectors. The delegation chains, per action signatures and offline verifiable receipts are real and available today. Integration into vault checkout and session brokering is proposed here as a reference design, not offered as a product. The privileged grant demo shows the signing step in a simpler setting.

What to do this week

1. Ask each of your top five suppliers, in writing, one question: for the people who hold privileged access to our systems, which legal entity employs or engages them, and how many organisations sit between you and them. The answers, and the delay before they arrive, are the finding.
2. Count your shared third party accounts. Not individual contractor accounts, shared ones. In most enterprises this number is larger than expected and nobody owns reducing it.
3. Take one recent privileged change made by a supplier and try to establish which human performed it, using only what you already have. Time the exercise. This is the cheapest possible demonstration of the gap and it costs an afternoon.
4. Check whether your third party register, if you keep one for regulatory reasons, records subcontracting at all, or only your direct counterparties. Under regimes such as the Digital Operational Resilience Act the subcontracting layer is explicitly in scope.
5. Classify your privileged actions by consequence, and identify the small set where you would genuinely want a named human signature. Gating everything is how these programmes die.
6. Write down what your emergency path is, who can use it, and how you would attribute an action taken through it afterwards.
7. Review the signing and delegation documentation if you want to see the chain verification mechanics rather than the argument for them.

Frequently asked questions

How do you identify which human at a managed service provider performed a privileged action? Today, usually you cannot, because the record attributes the action to an account or a vault checkout rather than a person. The durable answer is to require each privileged action to be signed on the technician's own enrolled device under a delegation chain issued by the client, so the client can walk the chain back to its own authority and verify it offline without asking the supplier.

Does privileged access management identify the person or the account? The account. Vaulting, session brokering, credential rotation and recording are all genuinely valuable, and the audit record they produce identifies a checkout against a directory entry that the supplier created and controls. Where that entry is a shared administrator account, which is common operationally, the record identifies a company and a role rather than a human being.

What does DORA require regarding third party access? The Digital Operational Resilience Act, applying since 17 January 2025, requires financial entities to maintain a register of information covering contractual arrangements with information and communication technology third party providers, including arrangements involving subcontracting of critical or important functions. It creates the obligation to know and control the chain without specifying the technical mechanism.

Why are managed service providers such attractive targets? Because of concentration. A single technician account at a provider serving hundreds of clients is effectively a key to hundreds of networks, so the return on compromising one provider is far higher than on compromising one enterprise. The 2021 Kaseya incident demonstrated publicly that provider tooling is a distribution channel as well as a service.

Is this different from an employee rotating within one supplier? Yes, and the two need different treatment. Churn within one supplier is a continuity problem: the same organisation, different people over time. Chain depth is a visibility problem: multiple organisations, only the first of which you have any relationship with. An enterprise can address churn contractually with its supplier. It cannot address depth that way.

Can we just ban subcontracting in our contracts? Some enterprises try, and it tends to produce either a price increase, worse coverage, or subcontracting that happens anyway and is simply not disclosed. The chain exists because it is economically rational at every link, so a prohibition fights the market rather than the risk. Requiring visibility and attribution is more achievable than requiring the structure to disappear.

Does the technician have to use a personal device? Not necessarily, but the key does need to belong to the individual rather than to whichever company employs them this quarter, otherwise you have recreated the original problem with better cryptography. In practice this can be a device the person controls across engagements, and the receipts that accumulate become a portable record of their verified work.

Sources

1. Verizon, 2025 Data Breach Investigations Report, for the reported increase in third party involvement in breaches and the methodology notes on how that category is defined. https://www.verizon.com/business/resources/reports/dbir/
2. Regulation (EU) 2022/2554, the Digital Operational Resilience Act, applying from 17 January 2025, including the register of information and provisions on subcontracting of critical or important functions. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
3. New York State Department of Financial Services, Part 500 cybersecurity regulation and its amendments, for third party service provider policy and access control obligations. https://www.dfs.ny.gov/industry_guidance/cybersecurity
4. Cybersecurity and Infrastructure Security Agency, advisories and guidance on managed service provider compromise, including the 2021 Kaseya incident. https://www.cisa.gov/news-events/cybersecurity-advisories
5. National Institute of Standards and Technology, Special Publication 800-53, access control and identification and authentication control families. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
6. ISO/IEC 27036, information security for supplier relationships. https://www.iso.org/standard/59648.html

A claim passed along four times is a rumour with paperwork. Authority that travels has to carry its own proof.