You contracted with a firm. You have no idea who is at the keyboard

Vendor risk management assesses the supplier. Access reviews confirm the account is approved. Neither asks the question that actually matters, which is whether the human using that account today is the human you interviewed. That gap is where named resource clauses go to die.

Picture a bank that has just signed a three year engineering contract with an offshore supplier. The statement of work names four engineers. Two of them were interviewed by the bank's own engineering manager, who liked them: strong, specific, clearly senior. The contract includes a named resource clause, because the bank's procurement team is competent and knows this is a risk. Everyone signs.

Onboarding happens over six weeks. Identity documents are checked, background screening is run through the supplier, laptops are shipped, VPN certificates are issued, badge photos are taken, accounts are created in the identity provider, and production access is granted on a staged schedule. It is a thorough process, executed properly, and at the end of it the bank has four accounts belonging to four verified humans.

Then the engagement runs for thirty months.

Somewhere around month five, one of the senior engineers is pulled onto a more valuable client. Somewhere around month nine, a second seat starts being shared between two junior developers on alternating shifts, because the supplier is short-staffed and the work is getting done, mostly. Somewhere around month fourteen, part of the work is quietly sub-contracted to a smaller firm in a third country, whose staff log in through the same accounts.

The bank's controls see none of this. The accounts are the same accounts. The VPN certificates are the same certificates. The access reviews pass every quarter, because the accounts are approved and the approvals are current. The badge photos still show the people who were interviewed. Every control is functioning exactly as designed, and the bank's answer to "who has had production access to our payments system for the last two years" is a list of four names, at least two of which are wrong.

What is contractor substitution and why does it survive good controls?

Substitution is what happens when the person delivering the work stops being the person who was approved to deliver it, without the client learning about it. It runs along a spectrum, and it is important to see the whole spectrum because the innocent end and the hostile end are indistinguishable to the client's systems.

The spectrum, from ordinary to hostile

At the benign end is ordinary operational reality. A supplier's senior engineer takes parental leave and a colleague covers, informally, for three weeks. Nobody intends deception. The work continues. Telling the client would trigger a change request, a re-onboarding, and a delay, so it is easier not to.

A step along is economic substitution, which is the classic outsourcing bait and switch. The seniors do the pitch and the interviews, and the juniors do the work. This is common enough that it has a name in procurement circles and is the reason named resource clauses exist at all. The supplier's margin improves considerably, and the client's outcomes degrade slowly enough to be attributed to something else.

Further along is seat sharing, where one approved account is used by two or more people, often across time zones so that a seat delivers more than one person's hours. From the client's logs this looks like an unusually diligent contractor who works long days.

At the hostile end, the substitution is the point. The entity in the contract and the person at the keyboard differ deliberately, because the person at the keyboard could not have passed the client's checks. That is the pattern behind the state-linked remote worker infiltration cases that have prompted enforcement action, which we cover separately in The laptop farm playbook. The important observation for this post is that the hostile version does not require any new technique. It uses the same gap the benign version uses, and the client's controls cannot tell them apart.

Why the client's controls miss all of it

Because every control in the standard third party stack answers a different question from the one that matters. Go through them.

Vendor risk management assesses the supplier as an entity: financial stability, security posture, certifications, insurance, subcontracting policy. It happens at contract time and repeats annually. It is genuinely useful and it is about the firm, not the humans. A supplier with an unimpeachable security programme can still put a different person in the seat on Tuesday.

Identity verification at onboarding checks a document against a face, once. It answers "is this person who they claim to be" on one day. The engagement lasts thirty months. This is the same moment-versus-duration mismatch we described in the identity continuity post, and it is the root of the whole problem.

Access reviews confirm that an account exists, is assigned to an approved person, and still needs its entitlements. Every access review in the world checks that the account is approved. None of them check who is behind it. An access review will happily certify, quarterly, for two years, an account being used by someone the client has never heard of.

VPN and badge logs record credential use and physical presence at a door. A credential is a thing that can be handed over. A badge photo is checked by a human at a reception desk, if at all, and not by the VPN.

Periodic video calls were the informal backstop for years: the client manager sees the contractor on a call and recognises them. That control has degraded sharply, because real-time face and voice synthesis is now cheap and improving faster than anyone's ability to spot it. Relying on visual recognition over a video call in 2026 is relying on a detector in a race it is losing, which is the argument we make at length in Detection debt.

The named resource clause itself is the most interesting failure, because it is the control specifically designed for this. It is a contractual promise with no telemetry attached. The client can enforce it only if it discovers a breach, and the only party who knows about the breach is the supplier, who has every incentive not to mention it. It is a clause enforced by the honesty of the party it constrains.

Why is this an identity problem rather than a vendor management problem?

Because the missing capability is not better paperwork about the supplier. It is a way to establish that the human acting today is the human who was approved, checked by the client, without depending on the supplier's cooperation.

That capability has a name in this series. It is identity continuity, and its absence is Identity Discontinuity: identity is verified as a discrete event at a boundary, and then assumed for a duration during which nothing re-establishes it. We first described it for employment in the hire-to-offboard post. Supply chains are the same failure with an extra party in the middle, and the extra party is the one holding the identity relationship.

Think of it like a building pass issued to a named visitor. The pass is checked carefully at issue, and then for the next two years it opens the door for whoever is holding it. Nobody in the building is behaving badly. The pass simply never asks a second question. Every control in the third party stack is a variation on checking that the pass was properly issued.

Framing it as an identity problem rather than a compliance problem changes what you build. If it is a compliance problem, you write a stronger clause, you demand attestations from the supplier, and you audit the supplier's HR records, all of which depend on the supplier telling you the truth. If it is an identity problem, you require evidence generated by the contractor's own device that the client can check itself, and the supplier's honesty stops being load-bearing.

How large is the exposure?

Larger than most organisations model, and harder to quantify than vendors selling into this space usually admit.

Industry breach reporting has for several years identified third party involvement as a leading and growing route into organisations, with the annual Verizon Data Breach Investigations Report among the most cited sources tracking that trend. We are going to describe that directionally rather than quote a percentage, because the definitions of "third party involvement" differ between report editions and between publishers, and a precise-sounding number here would be the kind of thing this series criticises elsewhere. The durable observation is that contractors and suppliers are a major access path and that their share has been rising, not falling.

The second half of the exposure is structural rather than statistical, and it is easy to verify inside your own organisation in an afternoon. Count the accounts in your identity provider that belong to non-employees. Count the entitlements attached to them. Compare that to the proportion of your security controls, security training, device management and monitoring budget that is actually applied to those accounts. In most organisations the two ratios are wildly different: contractors hold a substantial share of access and receive a much smaller share of the controls, because the controls were designed around an employment relationship that does not exist here. Surveys putting numbers on that gap circulate, and they are mostly vendor-produced with undisclosed sampling, so run the count yourself. Your own numbers will be more persuasive to your own board than anyone's survey.

Then there is the regulatory dimension, which has sharpened. In financial services in the European Union, the Digital Operational Resilience Act, which applies from January 2025, imposes obligations around third party ICT risk including contractual requirements and oversight of critical service providers. European Banking Authority outsourcing guidelines have long expected institutions to retain accountability for outsourced functions. Neither instrument, so far as we can determine, prescribes a specific person-level continuity check, and we are not going to claim they do. What they do is make "we could not have known who was working on it" an increasingly poor answer to a supervisor.

What does the control actually look like?

The design principle is that access binds to an enrolled individual rather than to a named seat, and that the evidence is produced by the contractor's own device and verified by the client directly.

Enrol at the interview, not at onboarding

This is the detail that makes the difference, and it is counterintuitive. Most schemes enrol at onboarding, which is weeks after the interview and after the supplier has had every opportunity to substitute. Enrolling at the interview binds the key to the person the client's engineering manager actually assessed and wanted. Everything afterwards is a comparison against that moment.

The interview continuity demonstration shows the mechanic: a person enrols during a video interview, and a later session can establish that it is the same human, using an on-device face match that produces a one-way key. No biometric template leaves the device and none is stored by the client or by us, which matters both for privacy law and for the contractor's willingness to participate.

Check at meaningful moments, not continuously

The temptation is to check constantly. Resist it, for two reasons. Continuous checking is surveillance, which contractors will refuse and works councils will block, and it is also unnecessary. The useful moments are few:

• First login to the client's environment, which is where a substitution made during onboarding would surface.
• Return after a gap of more than some period, which is where a quiet handover typically happens.
• Elevation to a sensitive action: production deploy, access to customer data, a privileged operation. This is the same logic as gating consequential actions rather than every action, which runs through the whole series.
• A small random sample of routine sessions, which is what makes systematic seat sharing statistically visible without watching anyone.

Everything else runs on the ordinary session. A contractor might encounter this six or eight times across a year-long engagement, which is a very different proposition from monitoring software.

What the client receives

{
  "type": "engagement.continuity.v1",
  "engagement_id": "SOW-2026-0417/seat-3",
  "supplier": "did:web:supplier.example",
  "subject_key": "z6MkpQ8fT2xW...",        // enrolled at interview
  "check": {
    "at": "2026-09-14T08:12:44Z",
    "trigger": "privileged-action",
    "method": "glance",                    // on-device face match, liveness
    "result": "match",
    "enrolled_at": "2026-01-22T14:03:10Z"  // the interview
  },
  "nonce": "3ab91f7c"
}

Note what is absent. No image, no biometric template, no location trail, no keystroke data, no productivity measure. The receipt asserts one narrow fact: at this moment, the human holding this enrolled key passed a live check, and that key was enrolled at the interview on this date.

The client verifies it without asking the supplier anything:

receipt = client_store.get(engagement="SOW-2026-0417", seat=3, latest=True)

key = fetch_published_key(receipt.issuer)      # published verification key
assert ed25519_verify(key, canonical(receipt), receipt.signature)
assert receipt.check.result == "match"
assert receipt.check.subject_key == seat_roster["seat-3"].enrolled_key
assert age(receipt.check.at) < policy.max_staleness

# the supplier is not consulted, and cannot suppress a failure

That last comment is the whole point. The supplier holds the commercial relationship and has the incentive to substitute quietly. Removing them from the verification path is what converts a named resource clause from a promise into a control.

Is this fair to suppliers?

It has to be, or it will be routed around, and a control that gets routed around is worse than no control because it produces false assurance.

Rotation is normal and legitimate. People leave, take leave, get promoted, get ill, and get moved onto work that suits them better. Professional services firms have always managed benches dynamically, and a client demanding that four specific humans work exclusively on their account for three years is making an unreasonable request that will be met with a polite yes and a quiet no.

So the objective is visibility, not restriction. A supplier should be able to change staffing whenever they need to. What changes is that the change becomes an event the client sees, because the new person must enrol before they can perform gated actions, rather than a handover of credentials that nobody records.

There is a genuine benefit to the supplier here, and it is worth stating because it is the thing that gets these schemes adopted rather than resisted. A supplier with an enrolled bench can prove its staffing to a client, which is a differentiator in bids against competitors who cannot. In a market where every supplier's proposal claims senior resources, being the one who can demonstrate it is worth real money. Suppliers who substitute aggressively will hate this. Suppliers who do not are currently being priced as though they do, and this lets them stop.

It also protects the contractor, which is the part usually left out. A named individual who is swapped off an engagement without consultation, or whose seat is quietly shared, has no way to demonstrate what they actually worked on. A receipt trail is theirs too, and it accumulates into verified tenure they can carry to the next engagement, which is the subject of the companion post on freelancer trust portability.

What this cannot do

Four limits, and the first is the one that keeps this honest.

It requires supplier cooperation to start. The contractor has to enrol, on their own device, and that enrolment happens inside a commercial relationship the supplier controls. A supplier determined to defeat this can enrol a proxy at the interview, so that the person who is checked throughout is consistently the wrong person, consistently. Continuity proves sameness, not correctness of the original identification. It converts an ongoing substitution risk into a single point of failure at enrolment, which is a large improvement and not a cure. Pair it with proper identity verification at enrolment, from a vendor whose job that is.

It does not see subcontracting you never learn about. If work is being done by a fourth party whose staff never touch your systems, because they hand deliverables to the supplier who then commits them under an enrolled account, continuity checks will pass and the work will still not be coming from where you think. This control governs access to your environment, not the provenance of everything delivered into it.

It is only as good as the device binding. A contractor who hands their enrolled phone to a colleague along with their credentials defeats the check for as long as the colleague holds it. Liveness makes casual sharing awkward and repeated sharing operationally painful, which is usually enough against convenience substitution and is not a barrier against a determined, coordinated arrangement.

The connectors are not shipped. Manav does not currently ship native integrations into identity providers, VPN concentrators or vendor management systems. What exists is the continuity mechanism, the receipt format and offline verification, which means this is implementable today as a step-up requirement in your own identity provider policy and is not a product you can buy pre-wired. Treat the architecture in this post as a reference design.

What to do this week

1. Pull the list of non-employee accounts in your identity provider and count them, along with their entitlements. Compare that to the share of your security controls that actually reach those accounts. Do this before you talk to any vendor, including us.
2. Find your named resource clauses and ask a simple question of whoever owns the contract: what telemetry would tell us if this clause were breached? If the answer is "the supplier would tell us", you have a promise rather than a control.
3. Identify your top five engagements by access sensitivity rather than by contract value. These are usually different lists, and the second one is the one procurement watches.
4. Define the gated actions for those engagements. Production deploy, customer data export, privileged elevation. Keep the list short enough that people will accept it.
5. Move enrolment to the interview for the next engagement you onboard, even if you do nothing else. It costs nothing and it is the step that everything later depends on.
6. Ask your three largest suppliers whether they would support person-level continuity checks. Their answers will be informative in ways the security questionnaire is not.
7. Check what your access review actually attests. If it certifies that an account is approved rather than who is using it, say so explicitly in the control description, so that nobody downstream over-reads it.
8. Read the receipt and verification formats in the developer documentation before you design something bespoke, and look at the rotating contractor demonstration to see the flow end to finish.

Frequently asked questions

How do you verify that the contractor working is the person who was interviewed? Enrol the contractor at the interview, so a key on their own device is bound to the human your team actually assessed. Then require a brief on-device check at first login, after long gaps, before privileged actions and on a random sample of sessions. The client verifies the resulting receipts directly, without the supplier in the verification path.

What is a named resource clause and why does it fail? It is a contractual term requiring that specific named individuals perform the work. It fails because it has no telemetry attached. The only party who reliably knows when it has been breached is the supplier, who has a commercial incentive to stay quiet, so enforcement depends on the honesty of the constrained party.

How common is contractor substitution in outsourcing? Nobody credibly knows, and be sceptical of anyone who gives you a percentage. Substitution is invisible to the systems that would have to record it, so there is no denominator. What is documented is that third party access is a major and growing route into breaches, and that deliberate substitution has appeared in state-linked remote worker cases prosecuted in several jurisdictions.

Is this just monitoring contractors? No, and the distinction is structural rather than rhetorical. Monitoring runs continuously, collects behavioural data, and is held by the employer. This produces a small number of discrete checks at defined moments, retains no biometric template, and issues a receipt the contractor also holds. If a product in this space wants continuous camera access or activity data, it is doing the other thing.

Does DORA require person-level identity checks for contractors? Not specifically, as far as we can determine, and treat any vendor claiming otherwise carefully. The Digital Operational Resilience Act, applying from January 2025, sets obligations around third party ICT risk management, contractual provisions and oversight. It raises the standard of what an institution is expected to know about its providers rather than mandating a particular identity control.

What happens when the supplier legitimately needs to change staff? They change staff. The new person enrols before performing gated actions, and the change becomes visible to the client as an event rather than being invisible as a credential handover. The design goal is visibility, not restriction, because a control that makes normal staffing changes painful will simply be evaded.

Can the supplier defeat this by enrolling a proxy at the interview? Yes, and this is the honest limit. Continuity proves that today's human is the same as the enrolled human. It does not prove the enrolled human was correctly identified in the first place. That is why it should sit alongside proper identity verification at enrolment rather than replacing it, and why moving enrolment to the interview matters so much.

Sources

1. Verizon, Data Breach Investigations Report. Annual series tracking breach patterns including third party involvement; definitions vary between editions, so compare like with like.
2. Regulation (EU) 2022/2554 (Digital Operational Resilience Act), EUR-Lex. Third party ICT risk obligations for financial entities, applying from January 2025.
3. European Banking Authority, Guidelines on outsourcing arrangements. Retained accountability for outsourced functions.
4. NIST, SP 800-53 Revision 5. Personnel security and access control families relevant to non-employee access.
5. ISO/IEC 27036, Information security for supplier relationships.
6. United States Department of Justice, press releases. Enforcement actions concerning remote information technology worker schemes using substituted identities.

A named resource clause without telemetry is not a control. It is a promise, enforced by the only party with a reason to break it.