Every engagement leaves credentials behind and no engagement is scoped to collect them

The engagement ran eighteen months. Three delivery pods, a payments integration, a data platform migration, a reconciliation batch rewritten twice. On the final Friday the closedown checklist is worked through properly, by people who take it seriously: twenty-two named consultant accounts disabled, laptops returned, VPN profiles revoked, workspace membership removed, badges handed in at reception. A partner signs the acceptance certificate. The client's identity team confirms in writing that no personnel from the supplier retain access.

That statement is true. It is also, in the sense the client will care about eighteen months later, beside the point.

Over those eighteen months the programme brought a second population of identity into existence. Service accounts for the nightly reconciliation. An API key issued for the payments gateway during integration testing that became the production key because it was already working. Deployment tokens held by the build system. Kubernetes ServiceAccount tokens mounted into pods that have not restarted since March. Cloud workload identities for the data pipeline. Two OAuth client registrations created so that vendor systems could call in. A break-glass administrative principal created at two in the morning in month four, during a production incident, by an engineer who has since left both organisations.

None of those appear on the closedown checklist. Not because anyone was careless. Because every one of them belongs to a system that is still running, and nobody wants to be the person who breaks production on the last day of an engagement.

The last Friday

The engagement above is a constructed illustration, assembled to make a mechanism visible. It is not drawn from any client, and no detail in it should be read as reporting an incident. Everything downstream of it — the specifications, the supervisory instruments, the vendor documentation — is cited to the primary publisher and can be checked.

Work through the last Friday slowly, because the shape of the failure is in the sequence rather than in any single decision.

The closedown checklist exists. Someone wrote it, and it is good. It was derived from the master services agreement, which was derived from the client's own supplier-security standard, which was derived from a control catalogue. It enumerates the things a departing supplier is understood to hold: accounts, devices, physical access, data extracts, documentation. Each line has an owner on both sides and a signature block.

The programme's engineering leads are also in the room. They know about the service accounts, in the sense that they created some of them and inherited others. Ask any one of them and they will list four or five without hesitation. Ask for the complete set and the answer changes shape: it becomes a question about which systems count, which environments count, whether the ones created by Terraform in a module a different pod owns are theirs, and whether the OAuth client the vendor registered on the client's behalf is a supplier artefact or a client artefact.

Nobody in the room is being evasive. The question genuinely does not have a determinate answer, and I will spend most of this piece on why.

So the meeting arrives, as these meetings do, at a reasonable compromise. The service accounts stay, because production runs on them. The client's platform team will "pick up ownership". A ticket is raised. The ticket says something like: review non-human accounts associated with Programme Atlas and confirm continued need. It is assigned to a queue. It is a P3.

Eighteen months later an auditor asks the client to demonstrate that every credential with write access to the payments environment has a named owner and a documented review. The break-glass principal from month four surfaces. It has been used four times since the engagement ended, all four by an automation the client's own team built on top of it because it was the only thing with the necessary permissions. Nobody can say who approved it, because nobody did — it was created during an incident, which is exactly when approval processes are suspended by design.

The strongest version of the objection

The best counter-argument to everything above is not that the residue does not exist. Everyone who has run a delivery programme knows it exists. The counter-argument is that it is not the supplier's problem, and that trying to make it one produces a worse outcome than leaving it alone. It deserves to be put at full strength, because it is substantially correct.

It runs like this. The identities in question are provisioned inside the client's own directory, under the client's own naming standard, subject to the client's own approval workflow, and they authenticate against the client's own systems. The supplier did not own them at any point; it requested them, and the client granted them. Every one of them was created through a change process the client operates. The client's identity and access management function has, by construction, a complete list — that is what the directory is.

Further: the identities exist because they are load-bearing. The reconciliation batch runs on the service account. Deleting it at closedown means the batch fails on Saturday morning, in an environment the supplier no longer has access to fix. A supplier that unilaterally revoked its own creations on exit would be doing something considerably more dangerous than leaving them in place, and would rightly be in breach.

And there is a governance version of the argument that is sharper still. In the United States, the interagency third-party guidance is explicit that a banking organisation's use of third parties "does not diminish its responsibility to meet these requirements". The duty is the client's. Inviting the supplier to take responsibility for the client's access management is not diligence; it is a category error, and one that regulators have specifically declined to endorse.

I think all of that is right, and none of it touches the argument.

Because the claim here is not that the supplier should own the identities after exit. It is that the supplier is the only party that ever held the information required to hand them over, and that none of the instruments examined later in this piece asks for it. The client's directory contains the objects. It does not contain the reason each one exists, which pod created it, which workload will break if it is removed, which of them were provisioned for a migration that finished a year ago, or which of the seven service principals with similar names is the one the batch actually uses. That knowledge lived in the delivery team, and the delivery team has been re-staffed onto other work.

The second half of the objection — that revoking on exit is operationally dangerous — is also right, and it is the reason the answer cannot be revocation. It has to be enumeration with attribution, which is a different and much cheaper thing. Nothing has to be switched off on the last Friday. Something has to be written down, in a form the client can act on later without the supplier in the room.

Nothing I could find defines the thing being counted

Here is the part that makes this structural rather than a process gap somebody will patch.

Ask how many machine identities an estate contains and you are asking a question with no determinate answer, because the phrase does not pick out a single class of object. This is not a measurement problem. It is a referent problem, and it is upstream of every count anyone has published.

Consider what different, entirely legitimate readings pick out, using only what the platforms document about themselves.

A directory principal. An object in a directory with a lifecycle, a display name and an owner field. This is the reading an identity team defaults to, because it is the population their tooling enumerates. It is also the reading that misses anything which authenticates without a corresponding directory object.

A role session. In AWS, assuming a role produces a set of temporary security credentials rather than a stored identity object. There is no durable thing in a directory to count; there is a policy attached to a role and a stream of sessions derived from it. Under this reading, a workload that assumes a role every five minutes is not one identity or thousands — the question is malformed.

A mounted token. Kubernetes documents two classes of ServiceAccount credential with opposite properties. Projected and TokenRequest tokens "expire automatically" and are rotated. Secret-based tokens are described as not recommended precisely because, in the documentation's own words, "these tokens don't expire and don't rotate". Two entirely different species of credential sit under one ServiceAccount object, and only one of them can fail closed.

A secret in a vault. A count of stored secrets counts artefacts, not principals. One principal may hold several; one secret may be shared by several principals, which is itself the defect. The number is real and auditable and answers a different question.

A secret in a commit. Source-control scanning counts occurrences in repositories. That population overlaps the others unpredictably and includes credentials that were revoked years ago alongside ones nobody knows are live.

These are not five estimates of one quantity with different error bars. They are measurements of five different quantities that share a label, and they differ from one another by more than rounding. Ratios of machine identities to human ones circulate widely in vendor literature, and set side by side they disagree with each other substantially. That last sentence is a characterisation of a body of vendor material rather than a measurement I am sourcing, and I am deliberately not going to quote any one of those figures — partly because the disagreement is not the interesting part, and mostly because none of the publishers is obliged to state which of the objects above it counted, so no two of the figures can be reconciled even in principle. A ratio published without its referent is a number with a label attached.

It is worth being precise about how far this goes, because it is easy to overclaim. I am not asserting that no body anywhere has published a definition; that is a universal negative and I cannot verify it. What I can show is narrower and, for this argument, sufficient: the two documents a services firm is most likely to be measured against do not supply one.

NIST SP 800-63-4, the 2025 final revision of the digital identity guidelines, states in its Scope and Applicability section that "For this publication, 'person' refers only to natural persons," and that the guidelines "do not explicitly address some subjects including, but not limited to, machine-to-machine authentication, interconnected devices (e.g., Internet of Things [IoT] devices), or access to Application Programming Interfaces (APIs) on behalf of subjects." The document most often cited as the authority on identity assurance says, in its own scoping language, that it is not about the objects in dispute.

NIST SP 800-53 Rev. 5 never uses the term "service account" in the sense the industry uses it. A full-text search of the published catalogue returns zero occurrences of the phrase, and Release 5.2.0 of August 2025 — which adds SA-15(13), SA-24 and SI-02(07) — does not introduce it or amend AC-2. The word appears as an account type exactly once, inside the non-normative Discussion under AC-2: "Examples of system account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service." It is an item in an illustrative list. No distinct lifecycle requirement attaches to it anywhere in the catalogue.

So the object that a statement of work would have to name, in order to require its handback, is an object that the two most-cited control documents in the relationship either exclude by name or mention once in passing. That is why this does not get patched by a better checklist. A checklist can only ask for things that have names.

// Five defensible readings of the phrase "machine identity", over one normalised estate.
// The estate is held constant. Only the predicate changes.

export type Platform = "entra" | "aws" | "gcp" | "kubernetes" | "vault" | "scm";

export type CredentialClass =
  /** An object in a directory, with a lifecycle and an owner field. */
  | "directory-principal"
  /** AWS STS assumed-role session: temporary credentials, no stored identity object. */
  | "role-session"
  /** Kubernetes Secret-based ServiceAccount token: documented as not expiring, not rotating. */
  | "mounted-token"
  /** Kubernetes TokenRequest / projected token: expires automatically, rotated by the kubelet. */
  | "projected-token"
  /** A long-lived key or password held in a secret store. */
  | "static-secret"
  /** A registered OAuth client with a credential of its own. */
  | "oauth-client"
  /** A secret discovered in source control. */
  | "committed-secret";

export type EstateRecord = {
  readonly id: string;
  readonly platform: Platform;
  readonly credentialClass: CredentialClass;
  /** False where the platform cannot express an expiry for this object at all. */
  readonly hasExpiry: boolean;
  /** Soft-deleted objects that still occupy tenant quota and still appear in some exports. */
  readonly softDeleted: boolean;
  /** Whether anything authenticated as this principal in the last 90 days. */
  readonly seenInLast90Days: boolean;
  /** Set where the object was created during a delivery engagement. Usually absent. */
  readonly createdByEngagement?: string;
};

export type Definition = (record: EstateRecord) => boolean;

export const definitions = {
  /** A. Live directory objects. What an identity team's tooling enumerates by default. */
  directoryObjects: (r) => r.credentialClass === "directory-principal" && !r.softDeleted,

  /** B. Directory objects including purge-pending ones, which still consume quota. */
  directoryObjectsIncludingPurgePending: (r) => r.credentialClass === "directory-principal",

  /** C. Anything that can present a credential, whether or not a directory object exists. */
  authenticatingPrincipals: (r) => r.credentialClass !== "committed-secret",

  /** D. Credentials with no expiry — the population that cannot fail closed. */
  nonExpiringCredentials: (r) => !r.hasExpiry,

  /** E. Secrets discoverable in source control. What scanning tools report. */
  secretsInSourceControl: (r) => r.credentialClass === "committed-secret",
} satisfies Record<string, Definition>;

export type DefinitionName = keyof typeof definitions;

Why the seam is exactly where it fails

The definitional problem is general. It bites hardest at a supplier boundary, and the reason is worth setting out carefully, because it explains why this is a services-sector argument rather than a generic identity-hygiene argument.

Provisioning and deprovisioning have different failure semantics, and the difference is not accidental. Provisioning is synchronous and on the critical path: if the service account is not created, the pipeline does not run, someone is blocked, and a ticket escalates within the hour. Deprovisioning is asynchronous and off the path: if it fails, nothing breaks, no alert fires, and the failure is recorded — where it is recorded at all — at a log level nobody reads. A system whose forward path is blocking and retried, and whose reverse path is silent and best-effort, accumulates. That is arithmetic, not culture.

Now add the organisational boundary. In a client-only setting, the accumulation is at least owned by a single organisation that will eventually notice — the platform team inherits its own debris. At a supplier seam, three additional things happen at once.

1. The knowledge and the object are separated. The client holds the object in its directory. The supplier held the reason it exists. At the moment of handback the two are in different organisations, and only one of them is contractually obliged to produce anything.
2. The moment of separation is the moment of maximum risk aversion. Closedown week is when nobody will authorise a change to production. It is precisely the wrong time to test whether a credential can be removed, and everyone in the room knows it, which is why the decision defers by default.
3. The delivery team dissolves immediately afterwards. Consultants are a re-staffing model. Within a fortnight the people who could have answered the question are on other accounts, and within a year some are at other firms. The information does not degrade gradually; it disappears on a known date.

There is a further wrinkle that the interagency guidance anticipates and most delivery models ignore. Under its subcontracting provisions, the guidance advises addressing "when and how the third party should notify the banking organization of its use or intent to use a subcontractor and whether specific subcontractors are prohibited", and whether the contract should prohibit "assignment, transfer, or subcontracting of the third party's obligations to another entity without the banking organization's consent". Where subcontracting is integral to the activity, it advises considering "more detailed contractual obligations, such as reporting on the subcontractor's conformance with performance measures, periodic audit results, and compliance with laws and regulations". (The often-quoted list of subcontractor risks — those with access to the banking organisation's infrastructure, those within extended chains — appears in the preamble as a summary of commenters' views, not as the agencies' own instruction; in response the agencies narrowed the guidance to the third party's own oversight processes and removed the term "critical subcontractor" altogether.) That is a direct description of how large delivery programmes actually staff: a prime, one or two specialist partners, an offshore capability centre, and a product vendor's professional-services arm, each of which provisions identities under the prime's engagement.

Which means the residue is not one supplier's residue. It is a tree, and the client sees only the root.

What fails at mechanism level

Suppose the argument so far is accepted and someone decides to act on it at the end of the next programme. What specifically breaks? It is worth being concrete, because the failures are not the ones people expect.

Enumeration returns a list that is not the list. A directory export returns directory objects. It does not return AWS role sessions, because those are temporary credentials rather than stored objects. It does not distinguish a Kubernetes Secret-based token from a projected one, though the first cannot expire and the second cannot persist. It includes soft-deleted principals in some tenants and not others. The export is accurate and incomplete in ways that are invisible from the export itself, which is the worst combination — it produces confidence.

Ownership resolves to a distribution list. SP 800-53 Rev. 5 does require the owner field. AC-2(b) is "Assign account managers", and AC-2(f) requires organisations to "Create, enable, modify, disable, and remove accounts in accordance with" an organisation-defined policy. So the control exists and the field exists. What the field usually contains, for an identity created during a supplier programme, is a mailbox that routes to a team that no longer has anyone who was on that programme. The control is satisfied. The information is not there.

The deprovisioning trigger never fires. This is the important one. AC-2 closes with item (l): "Align account management processes with personnel termination and transfer processes." That is the trigger the whole apparatus hangs on, and it is a human resources event. There is no corresponding requirement that anything fire when a workload is decommissioned, a migration completes, or an engagement ends. The catalogue asks for an owner and a removal process, and then anchors removal to a person leaving. For an identity attached to a batch job, no such person exists.

The one control aimed at suppliers covers people only. PS-7, External Personnel Security, requires organisations to "Require external providers to notify [organization-defined personnel or roles] of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within [organization-defined time period]." Its Discussion names "service bureaus, contractors, and other organizations that provide system development, information technology services" as exactly the providers in view. So the catalogue does contemplate a notification duty running from supplier to client — and scopes it to personnel. There is no parallel control requiring a provider to notify the client when a machine credential the provider created is no longer needed.

Revocation is not what the word implies. Even where someone does decide to remove a credential, the removal is a probabilistic, time-bounded process rather than an event, and the platforms say so themselves.

RFC 7009, the OAuth token revocation standard, states in section 2 that "Implementations MUST support the revocation of refresh tokens and SHOULD support the revocation of access tokens" — so revoking the credential actually presented to a resource server is optional at the specification level. Section 2.1 says invalidation "takes place immediately", and then immediately qualifies it: "in practice, there could be a propagation delay, for example, in which some servers know about the invalidation while others do not." Section 3 goes further, noting that where self-contained access tokens are used, "some (currently non-standardized) backend interaction between the authorization server and the resource server may be used when immediate access token revocation is desired." As of that specification, there is no standard mechanism for making revocation take effect at the resource server.

RFC 9068, the standards-track profile for JWT access tokens published in October 2021, confirms the gap operationally. Its section 4 requires the resource server to verify the typ header, the issuer claim, the audience claim, the signature, and that "the current time MUST be before the time represented by the 'exp' claim". It specifies no revocation check and no introspection call. A resource server that accepts a revoked-but-unexpired JWT is not misbehaving; it is conforming.

The cloud platforms publish their own bounds. AWS documents that revoking an IAM role session does not invalidate the credential at all — it attaches an inline deny policy, named AWSRevokeOlderSessions, which "denies all access to users who assumed the role in the past as well as approximately 30 seconds into the future. This future time choice takes into account the propagation delay of the policy in order to deal with a new session that was acquired or renewed before the updated policy is in effect in a given region." The AWS command line interface user guide adds the other half: "The AWS CLI caches credentials until they expire", and where a role's temporary credentials have been revoked it tells operators to delete the local cache by hand. Revocation there is a policy race with a deliberate forward margin, not a credential death.

Google Cloud is more explicit still. Its IAM documentation states that access changes "are eventually consistent", that policy changes take "typically 2 minutes, potentially 7 minutes or longer", that group membership changes take "typically several minutes, potentially hours or longer", and that "in the meantime, recent access changes might not be effective everywhere. For example, principals might still be able to use a recently revoked role or a recently denied permission." That is a quantified, primary answer to how long revocation takes to bite, and it is measured in minutes to hours.

Microsoft publishes the exposure window for its own platform: "When issued, the Microsoft identity platform assigns a random value ranging between 60-90 minutes (75 minutes on average) as the default lifetime of an access token," with long-lived token lifetimes ranging "from 20 to 28 hours". And Kubernetes documents the case with no bound at all — projected and TokenRequest tokens "expire automatically" and rotate, while Secret-based ServiceAccount tokens are described as not recommended precisely because "these tokens don't expire and don't rotate".

Those are published bounds, not failure rates. I looked for a primary quantitative study measuring how often revocation silently fails to take effect, or the observed distribution of time-to-actual-revocation across real estates, and did not find one. Treat the vendor numbers as upper bounds on exposure, not as evidence about how often the exposure is realised. Anyone quoting a failure rate for this should be asked who measured it.

What the instruments already say, and where they stop

The field is not silent here. It is close, in several places, and each time it stops one step short. Setting out where is the most useful thing this piece can do, because it tells a services firm exactly which sentence in which document its statement of work has to extend.

A caution first, and it matters for this sector specifically. A services firm has no instrument of its own. It inherits whatever governs the client, and the obligation that is genuinely its own is contractual. So every instrument below is cited as the client's, and I say which client.

NIST CSF 2.0 is the one that names them. Subcategory PR.AA-01 reads "Identities and credentials for authorized users, services, and hardware are managed by the organization", and PR.AA-03 reads "Users, services, and hardware are authenticated." That is non-human identity treated as a first-class subject, in a widely-adopted framework, in plain words. It is also, by the framework's own account, not a control: the document states that the framework "does not prescribe how outcomes should be achieved". So it establishes the obligation and specifies nothing about how to meet it, leaving the how entirely to the contract.

CSF 2.0 also carries the post-engagement hook. GV.SC-10 reads: "Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement." GV.SC-05 requires that supply-chain security requirements be "established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties." Those two subcategories are the closest thing in general use to a measuring stick for a supplier's exit obligations — and neither names an identity, a credential, or a revocation test. They are the right hook with nothing hanging from it.

The US interagency third-party guidance names what comes back, and identity is not on the list. For a banking client in the United States, the governing supervisory expectation on this relationship is the Interagency Guidance on Third-Party Relationships: Risk Management, published at 88 FR 37920 on 9 June 2023 and issued by the OCC as Bulletin 2023-17. Under "p. Default and Termination" it advises contractual provisions that "Provide for the timely return or destruction of the banking organization's data, information, and other resources." Data, information, resources. Not credentials, not keys, not accounts, not the service principals the engagement created.

The same guidance does put systems access squarely inside due diligence — it lists "Understanding potential information security implications, including access to the banking organization's systems and to its confidential information" — and under "h. Confidentiality and Integrity" notes that "there may be increased risks related to the sensitivity of non-public information or access to infrastructure", with contracts that "typically prohibit the use and disclosure of banking organization and customer information by a third party and its subcontractors". Access is scoped carefully at deal time. Its withdrawal is not scoped at exit.

And the guidance is explicitly non-binding, which is exactly why the contract is the live instrument rather than a fallback. It states that "supervisory guidance does not have the force and effect of law and does not impose any new requirements", while holding that "a banking organization's use of third parties does not diminish its responsibility to meet these requirements". The duty stays with the client. The guidance specifies no controls. Therefore whatever is handed back is whatever the statement of work said would be handed back — and nothing else.

India's instrument is more prescriptive than the American one. For a regulated Indian client, the binding text on this relationship is the Reserve Bank of India (Outsourcing of Information Technology Services) Directions, 2023 — RBI/2023-24/102, dated 10 April 2023. It goes considerably further than the US guidance. Chapter V sets minimum contents for the outsourcing agreement, including effective access by the regulated entity to all data, books, records, information, logs and alerts, and to business premises. Sub-contracting requires prior consent and the provider remains contractually liable for its sub-contractors, with the right of audit extending down the chain. Chapter X requires an exit strategy covering safe removal or destruction of data, hardware and all records, and prohibits the provider from erasing data during the transition period. Clause numbering should be re-verified against the current Master Direction before it is quoted in a contract.

Note what that instrument does and does not do. It closes the sub-contracting gap in a way the US guidance only advises on, and it is genuinely enforceable rather than advisory. It still enumerates data, hardware and records at exit. The identity is not in the list there either — but the audit and access provisions give a client's counsel more to work with than "other resources" does.

The Gulf instrument comes closest to naming the object. For a Saudi client, the SAMA Cyber Security Framework is, of the instruments examined here, the only one that addresses non-human privileged accounts directly. Under control domain 3.3.5, Identity and Access Management, it requires that non-personal privileged accounts be limited and monitored, that password confidentiality be maintained with passwords changed frequently at session end, that privileged and remote accounts be reviewed periodically, and that an audit trail of access requests, approvals and revocations be maintained. That is closer to the object than anything in the US or Indian texts. It is also worth noting that the SAMA Rulebook page carries a "Soft Launch" label dated 24 May 2017, so the currently effective framework version should be confirmed before any of it is cited into an agreement.

Put the row of them together and a pattern falls out that is more interesting than any single gap. Three separate instruments — CSF 2.0, the US interagency guidance, and the RBI directions — create an obligation to hand something back at the end of a supplier relationship. In none of them is the something an identity. One framework names non-human identity as a first-class subject and then declines to prescribe. One control catalogue requires an owner and a removal process and anchors the trigger to a person leaving. One control places a notification duty on the supplier and scopes it to personnel.

The gap is not hidden. It is the shape left by every instrument above stopping one step short of the same point.

The limits of this argument

Several things could be true that would substantially weaken what I have argued, and it is worth naming them precisely enough that someone could go and check.

The residue might be small. I have argued that the mechanism produces accumulation. I have not shown how much. It is entirely possible that in a well-run estate the orphaned population is a handful of objects, all of them low-privilege, and that the audit finding is embarrassing rather than material. I have no primary measurement of the size of the residue in real engagements, and I am not going to invent one. What would settle it is a study that enumerates identities created during a defined delivery programme and re-checks their status at twelve and twenty-four months post-exit. I have not found one. If someone runs it and the answer is small, this argument reduces to a hygiene point.

Modern platform practice might be closing it without anyone writing it down. The strongest technical objection. Workload identity federation, short-lived tokens, projected Kubernetes tokens and infrastructure-as-code provisioning all push in the direction of credentials that expire by default and objects that are destroyed when their defining code is removed. An estate built entirely that way in the last three years may not accumulate at all, because the identity has no independent existence outside the Terraform state that created it. If that pattern is now dominant in new build, the argument applies to legacy estates and shrinks over time. My own read is that this describes the newest layer of a large client's estate and not the bulk of what sits underneath it — but I want to be clear that this is a judgement formed from what I have seen, not a measurement, and I am not going to attach a proportion to it that I cannot defend. Someone with telemetry across many estates could settle it, and should.

The definitional problem might be solved by a body I have not checked. I have shown that two specific NIST documents exclude or barely mention the object. I have not shown, and cannot show, that no standards body anywhere defines it. If a definition with genuine adoption exists — one that a client's counsel and a supplier's delivery lead would both accept as picking out the same set of objects — then the enumeration problem becomes tractable much faster than I have implied, and the argument becomes contractual drafting rather than a structural claim. Anyone who has such a definition should send it, because it would be the most useful thing in this whole area.

Contract language might already exist somewhere. I looked for a primary published master services agreement or deliverable-acceptance template that requires enumeration of every identity created during an engagement, or a tested revocation path as an acceptance condition. I did not find one. That is an absence of evidence from a limited search, not proof that no such clause is in use — plenty of contracts are not public. If a firm has that clause and it works, the interesting question is what its acceptance criterion actually says, because that is the hard part.

And the framing might be self-serving. A consultant arguing that consulting engagements create an unexamined risk, which consultants are well placed to address, should expect the obvious reading. The defence is that the argument cuts against the interest it appears to serve: it says the supplier's own delivery model is a significant source of the problem, that the fix is contractual rather than a new workstream, and that the deliverable is a document rather than a platform. If the answer here were a product, I would be more suspicious of it too.

What the architecture would have to do

I am not going to build it here, because the construction is a separate piece and because building it now would let the reader skip the part that matters. But the teardown does constrain the shape of any answer, and the constraints are worth stating so that a bad answer is recognisable.

Anything that works has to satisfy four conditions that follow directly from the failures above.

• It has to name the object before it counts it. A handback artefact that says "all service accounts" inherits the definitional problem and will be argued about at exactly the moment nobody has time to argue. The definition has to be written into the engagement at signature, in terms of the specific platforms in scope, and it has to be narrow enough that two people counting independently get the same number.
• It has to record meaning, not just existence. The client's directory already holds the objects. What handback has to add is what each one is for, which workload consumes it, what breaks if it is removed, and who on the client side is accepting it — none of which the directory can hold and none of which survives the delivery team's re-staffing.
• It has to be produced continuously, not at closedown. Closedown week is the worst possible moment to attempt any of this: the knowledge is already leaving, the risk appetite is at its lowest, and the commercial relationship is at its most delicate. The artefact has to be a by-product of provisioning, updated when an identity is created, or it will not exist.
• It has to make revocation a tested path rather than an assumption. Given what the specifications and the platforms publish about propagation, the useful acceptance criterion is not "a revocation API exists" but a measured elapsed time from decision to a real call failing, recorded once, for at least the highest-privilege identities in the set.

Notice that none of those requires switching anything off on the last Friday. That was the strong form of the objection, and it survives: unilateral revocation at exit is genuinely dangerous and should not happen. Everything above is enumeration and attribution, which costs delivery time and breaks nothing.

Notice also where the obligation has to live. Not in the client's control catalogue, which anchors removal to a person leaving. Not in the supervisory guidance, which is explicit that it imposes no new requirements and prescribes no controls. In the statement of work — the one instrument in this relationship that is genuinely the services firm's to write, and the one place where the object can be given a name that both parties have agreed to.

The companion piece, "Credential lifecycle as an engagement deliverable", takes that on: what the artefact contains, where it sits in a delivery method so that it is produced as a by-product rather than a closedown task, what an acceptance criterion looks like that a client's counsel would sign and a delivery lead would not quietly ignore, and how to price the thing without it becoming a change request. It is forthcoming.

The reason to own this rather than wait for it to be asked for is not principally a risk argument. It is that the alternative is a client discovering it during an audit, eighteen months after acceptance, with a partner's signature on a certificate stating that no personnel from the supplier retain access — which was, and remains, entirely true.