The integration service account that reads every record has no owner and no expiry

The account described in the opening section, and referred to throughout, is a constructed illustration assembled from publicly documented mechanisms and from the plain text of the rules cited below. It is not a client system, not an incident report, and no part of it describes work done for any organisation. Where a failure is illustrated rather than sourced, the text says so at that point.

The account

It has a name like SVC_HL7IF_PRD, or INTEG_EMR_RO, or something shorter and less explicable that was typed once into a migration runbook in 2019 and has never been typed again. It authenticates to the record system with a password or a key that does not expire. It holds read access across the estate, not because anyone decided it should, but because the migration needed to reconcile records across service lines and the fastest way to satisfy that requirement on a deadline was to grant the account the widest read role available and revisit the scope later.

The revisit did not happen. The engineer who created it moved to a different employer two reorganisations ago. The ticket that authorised its creation is in a system that was decommissioned. The account's documented owner is a distribution list that now resolves to four people, none of whom were in the organisation when it was made, and all of whom, asked directly, will say honestly that they do not know what it does.

What it does, in fact, is more than anyone can enumerate. Over seven years it accreted callers. The nightly reconciliation job uses it. The oncology registry extract uses it. A reporting tool that was replaced twice still uses it, because the replacement inherited the connection string. A vendor-supplied interface engine uses it for a subset of message types nobody has mapped. Somewhere in the estate is a scheduled task that uses it once a quarter, and the only way to find out is to break the account and wait for a phone call.

So it appears in the access review. It appeared in the last one, and the one before, and the one before that. Each review flagged it correctly: broad standing access, no expiry, owner unverifiable. Each review deferred it, and each deferral was written by a competent person making a defensible judgement, because the estimated blast radius of rotating a credential with an unknown dependency graph, inside systems that clinicians use during a shift, exceeded the estimated risk of leaving a credential in place that has never, as far as anyone can tell, been misused.

Now something new points at it. An agent — a model with tools, running some workflow around prior authorisation, or coding, or care-gap closure — needs to read from the record system, and the fastest way to give it that read is the connection that already works. Nobody proposes this in a design document. It happens because a service account with broad read access and no expiry is, from an integration engineer's perspective, the path of least resistance that has been sanctioned by seven years of continuous operation. The agent inherits a permission that predates it, that nobody can scope, and that no instrument in the estate can attribute to a decision.

That is the object this essay is about. Not the agent. The credential the agent was handed.

The strongest case for leaving it alone

The argument for deferral is better than its critics allow, and it deserves to be stated at full strength before anything is said against it.

Availability is a patient-safety property, not an operational preference. A record system that stops answering during a shift is not an inconvenience; it is a clinical event. Downtime procedures exist, and they are worse than the system: paper, transcription lag, reconciliation error afterwards. An identity-hygiene change that has a five per cent chance of interrupting an interface feeding a clinical workflow is being weighed against a credential that has produced no observed harm in seven years. A risk officer who declines that trade is not being lazy. They are correctly observing that the certain, bounded, immediate harm of an outage dominates the uncertain, diffuse, deferred harm of a standing permission.

The dependency map is genuinely unknown, and unknowability is not a failure of diligence. In an estate that has absorbed two mergers, three reporting platforms and a vendor interface engine, no inventory is complete, and the incompleteness is not evenly distributed: the systems most likely to be missing from it are the oldest, least instrumented and most load-bearing. Discovery by breakage is the only exhaustive method available, and discovery by breakage in a hospital is not available. The team that says it cannot enumerate the callers is telling the truth.

The compensating controls are real. The account is usually network-restricted, its traffic is usually logged, its authentication events are usually monitored, and its access is read rather than write. A defender can say, with justification, that they have wrapped an ungovernable credential in governable controls, and that this is what defence in depth means in a brownfield estate. The purist position — no standing broad access, ever — has the disadvantage that I could find no account of its being implemented in this sector under a no-downtime constraint.

And the account is not, in fact, unmonitored. It is one of the most-watched objects in the estate. It is on every review list. It has a risk-register entry with a compensating-control narrative and a named accepted-risk approver. In the vocabulary of most control frameworks it is not an unknown; it is a known, accepted, documented exception, which is precisely what those frameworks provide for.

All of that is correct, and none of it answers the objection. The objection is not that the account is dangerous. The objection is that the organisation cannot say what it is. Every one of the defences above is a statement about the risk of the account's behaviour. None is a statement about the account's identity — who holds it, on whose authority, for what scope, until when. And it is identity, not behaviour, that the sector's rules ask about, that an accounting of disclosures needs, and that a reviewer will ask for years later when the behaviour is no longer reconstructible.

A label without a unit

The reason the second question is hard is not local to any hospital. It is that the object in question has no agreed definition, anywhere, and the numbers published about it are therefore not comparable.

Anyone who has read industry material on machine identity has seen ratios: so many non-human identities for every human user. The figures vary by close to an order of magnitude across publishers. The usual explanation is that estates differ, or that methodologies have different error bars. That explanation is wrong, and the way in which it is wrong is the whole argument of this piece.

The published figures are not estimates of one quantity taken with different instruments. They are measurements of different quantities that happen to share a label. One publisher counts rows in an identity directory whose type is marked as a service account. Another counts workload identities minted by a platform, which the directory never sees. Another counts secrets stored in a vault, which is a count of objects rather than principals — a single identity holding four secrets contributes four, and a single secret shared by four systems contributes one. Another counts credentials observed in traffic during a window, which by construction excludes anything dormant. Another counts credentials ever issued, from an issuance log that never decrements. Averaging those five is not a more accurate estimate of anything; it is a category error with a decimal point.

I have deliberately not quoted a ratio in this essay. In preparing it I could not verify any of the widely circulated figures against the publisher's own primary report, and at least one commonly cited anchor appears to derive from a survey of security decision-makers — that is, an average of respondents' impressions — rather than from an enumeration of credentials. Quoting two such numbers side by side, as though they were points on a single scale, would commit precisely the error the essay is diagnosing. If that leaves the section without a headline number, the absence is the finding.

The healthcare-specific version of the absence is starker. Searching for a hospital or health-system machine-identity ratio with a named publisher and a stated counting method returned nothing usable: cross-sector vendor studies that mention healthcare in passing, and no primary measurement scoped to the sector. A sector in which the consequences of an unattributable permission are unusually legible, heavily litigated and closely regulated turns out to be one where I could find no published measurement of the population at all. That is a stronger statement of the problem than any ratio would have been.

This matters beyond measurement hygiene, because a unit is a precondition for a duty. An obligation to inventory something you cannot define is unenforceable in practice and unauditable in principle. It is why the service account survives review after review: the review can name it, but the organisation has no schema in which the account is a record with required fields, so there is nothing that can be marked incomplete. The account is not an exception to the inventory. It is evidence that there is no inventory, only a list.

One correction is worth making here to a common framing. This is often described as a governance gap that better tooling will close. It is more accurate to call it a definitional gap that tooling has an incentive to leave open: every vendor's discovery product defines the unit as whatever its collector can see, and each such definition is internally coherent. Nothing in the market pushes toward a shared unit, because a shared unit would make products comparable. The gap is stable, which is why it should be treated as structural rather than as a backlog item.

What the regulation already calls a principal

Against that definitional vacuum sits a body of rules that is considerably less vague than practitioners assume, and considerably older.

The HIPAA Security Rule's Access Control standard at 45 CFR 164.312(a)(1) requires a covered entity to implement technical policies and procedures for electronic systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in 164.308(a)(4). The phrase that matters is persons or software programs. The regulation, written in 2003 and amended in 2013, already treats a software program as a rights-holding principal in the same clause as a human being. There is no interpretive leap required to apply it to an agent, because no leap was ever required to apply it to an integration.

The paired implementation specification is where it becomes concrete. 45 CFR 164.312(a)(2)(i), Unique User Identification, requires the covered entity to assign a unique name and/or number for identifying and tracking user identity. It is a required specification, not an addressable one — meaning the entity does not get to document a rationale for doing something equivalent instead. A shared service account used by an unknown set of callers, one of which is now an agent, does not assign a unique identifier to the principal doing the work. That is not a hygiene shortfall to be scheduled. It is a defect at the point of use, in a required specification, on a system holding protected health information.

Then there is termination. 45 CFR 164.308(a)(3)(ii)(C) requires procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends. Practitioners read this as an offboarding control for employees. The load-bearing words are or other arrangement with. The duty attaches to the ending of an arrangement, not to the deletion of a row in a human resources system — and an integration built for a migration that concluded in 2019 is an arrangement that ended seven years ago, whatever the account's login history says.

Two qualifications are owed here, and both cut against a simple reading. First, 164.308(a)(3)(ii)(C) is currently an addressable implementation specification, not a required one. Second, that is precisely the provision the pending Security Rule rulemaking proposes to change. The notice of proposed rulemaking, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, was published at 90 FR 898 on 6 January 2025 under RIN 0945-AA22, and proposes among other things to remove the distinction between required and addressable specifications with limited exceptions, to require a technology asset inventory and a network map showing how protected health information moves through systems, to require notification of certain other regulated entities within 24 hours when a workforce member's access is changed or terminated, and to require restoration of certain systems and data within 72 hours.

Status check, stated because the word addressable carries the argument: as of 18 August 2026 RIN 0945-AA22 has not been finalised. The Spring 2025 Unified Agenda listed it in the final rule stage with final action projected for May 2026; that date has passed unmet, and the current agenda entry moves the rule to long-term actions with final action projected for July 2027. I took that change from law-firm briefings reporting the agenda rather than from the agenda's own table, which did not render for automated retrieval, so treat the July 2027 date as reported rather than confirmed. Treat the paragraph above as describing a proposal in any case, and note that the 24-hour and 72-hour figures were read from HHS-hosted summary material rather than from the preamble directly, because hhs.gov refuses automated retrieval.

The direction of that proposal is worth naming plainly. A 24-hour propagation requirement on access changes and a mandatory asset inventory are, in substance, a requirement that machine and human principals have owners and that changes to their rights travel within a bounded time. That is the same requirement this essay says the estate cannot currently meet, arriving from the regulator rather than from a framework.

One precedent shows the duty is enforceable rather than theoretical. The HHS Office for Civil Rights settled with Pagosa Springs Medical Center, a Colorado critical access hospital, for $111,400 with a corrective action plan, after a former employee retained remote access to a web-based scheduling calendar containing protected health information; OCR found impermissible disclosure affecting 557 individuals and found that the hospital had failed to deactivate the former employee's username and password after termination, alongside a separate finding that no business associate agreement was in place with the calendar vendor. The relevant point is not the sum. It is that the account was still live is a finding an enforcer has already made, in writing, about a credential that outlived its arrangement.

The Pagosa Springs details above were read from HHS-hosted page content rather than by direct retrieval of the resolution agreement and corrective action plan, because hhs.gov returns HTTP 403 to automated requests. Anyone relying on this precedent should open the signed agreement and confirm the figures and cited provisions.

A note on the instrument practitioners most often reach for, and should not, in this context. Supervisory model risk management guidance was revised by OCC Bulletin 2026-13, Model Risk Management: Revised Guidance, of 17 April 2026, with the parallel Federal Reserve issuance SR 26-2; it supersedes SR 11-7 and SR 21-8, which should now be cited only as superseded. OCC 2026-13 states that generative and agentic AI models are not within the scope of that guidance, and that it does not set forth enforceable standards. That wording is the OCC's own. The correct reading is deferral, not exemption: nothing was subtracted from the obligations attaching to the underlying action, and what was removed is the framework that would have specified the controls. For a hospital the practical consequence is simple — do not expect a model risk framework to tell you what to do about the service account, and do not read its silence as permission. The duties engaged here are the ones attached to the act of touching the record, and those are in the Code of Federal Regulations, not in supervisory guidance.

Three clocks, and the one that is only advice

The second structural reason the account survives is that the sector's own binding text does not agree with itself about how long a credential should live, and the mechanism for shortening one is weaker than practitioners believe.

Start with the strongest fact available, because it is unusual and it is favourable. Healthcare is one of the few sectors in which a regulator has fixed a maximum tolerable revocation latency in binding text. ASTP/ONC certification criterion 45 CFR 170.315(g)(10)(vi) requires that a certified authorization server must be able to revoke and must revoke an authorized application's access at a patient's direction within one hour of the request. Not within one hour of the administrator acting. Within one hour of the request. The clock starts with the human being who asked.

The same criterion mandates long-lived credentials. 45 CFR 170.315(g)(10)(v)(A)(1)(ii) and (iii) require the authorization server to issue a refresh token valid for a period of no less than three months to confidential applications and to native applications capable of securing a refresh token, and (v)(A)(2)(ii) requires reissue for a new period of no less than three months on refresh. A certified healthcare API is therefore required by regulation to hold a three-month credential and required by regulation to stop it inside an hour.

These are not in conflict if, and only if, the revocation path works. That is the entire load the revocation path is carrying: it is the only thing reconciling two mandates that otherwise contradict each other. It is not an optimisation, and it is not a nice-to-have that a mature team adds later. In a certified system it is the mechanism that makes the certified configuration coherent.

Now the machine-to-machine case, which is the one the agent is in. HL7's SMART App Launch Implementation Guide v2.0.0 — the version incorporated by reference at 45 CFR 170.215(c)(2) — takes the opposite approach for system-to-system access. In the Backend Services profile, access tokens issued under the profile SHALL be short-lived and the expires_in value SHOULD NOT exceed 300, that is five minutes; refresh tokens SHOULD NOT be issued; and the specification defines no revocation mechanism for backend clients at all.

Read that as an admission rather than an omission. The standard's authors, facing system-to-system access with no user in the loop to revoke on, chose a five-minute expiry as the mitigation for an absent revocation path. The controlled variable is not whether revocation exists. It is how long the window is between a decision to stop something and the thing actually stopping. The standard set that window to five minutes by construction, and then did not need a revocation endpoint.

Which brings us to what revocation actually does when it is available. RFC 7009, OAuth 2.0 Token Revocation, has been a Standards Track document since August 2013, and it is candid about its own limits. Section 2.1 provides that where the token being revoked is a refresh token, the authorization server SHOULD also invalidate all access tokens based on the same authorization grant — a recommendation, not a requirement, and applicable only if the server supports access token revocation in the first place. Section 3's implementation note goes further: for self-contained tokens, some currently non-standardised backend interaction between the authorization server and the resource server may be used when immediate access token revocation is desired.

Put the three clocks together and the shape of the failure is visible. A certified server must issue a credential lasting at least three months. A patient may demand that access ends within an hour. The cascade from revoking the long credential to killing the short ones is a SHOULD. And for self-contained tokens the mechanism that would make it immediate is described by the standard itself as non-standardised. The one-hour rule is met, in a great many deployments, by an administrative action whose propagation time nobody has measured.

Now return to the service account, which is worse than any of this, because it is not in the token economy at all. It authenticates with a static secret. There is no expiry to bound the window, no grant to cascade from, and no authorization server that has an opinion about it. The mechanisms above are the sector's good case. The account is the case that predates them.

Why the review defers, every time

It is worth being precise about the mechanism of deferral, because the usual account — organisational inertia — is both unkind and analytically useless.

The deferral is the output of a comparison between two quantities that are not commensurable. On one side: the probability that rotating a credential with an incomplete dependency map interrupts a clinical workflow, multiplied by the harm of that interruption. That quantity is estimable, immediate, and owned by a named person who will be asked about it the same week. On the other side: the probability that an unattributable permission produces a regulatory or legal consequence, multiplied by the harm of that consequence, discounted over a horizon of several years, and owned by nobody in particular because the person who will answer for it has not been hired yet.

A rational actor with a quarterly review cycle defers, correctly, every time. And because the comparison does not change between reviews — the dependency map does not become more complete by being deferred, and the accreted callers only increase — the deferral is not a delay. It is a stable equilibrium. This is the sense in which the account is structural. There is no sequence of individually rational review decisions that ends with the account being retired.

Three properties keep the equilibrium stable, and each is worth naming because each suggests a different intervention.

1. The cost of the fix is concentrated and immediate; the cost of the defect is diffuse and deferred. This is not a bias to be corrected by exhortation. It is an accurate perception of who bears which cost and when.
2. The remediation available in the literature assumes a maintenance window. Rotate the secret, restart the dependants, verify. Every step of that assumes you can take the integration down for a bounded period and that a failure is recoverable by rollback. A hospital record system integration satisfies neither assumption reliably, so the standard advice is not merely hard here; it is inapplicable, and advice that is inapplicable is ignored rather than argued with.
3. The defect has no unit, so it cannot be tracked to closure. A finding that reads broad standing access, owner unverifiable has no field that can be filled in to make it complete. It can only be re-observed. Findings that cannot be closed are, over enough cycles, reclassified as conditions.

Nobody is choosing convenience over safety here. They are choosing a small, certain, this-week risk of breaking something a clinician needs over a large, uncertain, some-year risk of not being able to explain something to a regulator. Given how those two risks land on the person deciding, the choice is the correct one every quarter — and that is exactly why the account is still there after seven years.

The consequence for an agent programme is direct. An agent introduced into this estate does not create the problem; it inherits it, and it changes its character in two ways. It raises the rate at which the credential is exercised, so the volume of actions attributable only to a shared name increases sharply. And it introduces non-determinism into what the credential is used for, so the historical argument — we know what this account does, it has done the same thing for seven years — stops being available at the moment the organisation most needs it.

The evidence horizon

The reason all of this converts from a hygiene problem into a legal one is that healthcare's obligations run for a long time, on several clocks at once, and they run on the identity, not only on the data.

45 CFR 164.316(b)(2)(i) requires a covered entity to retain the documentation the Security Rule requires for six years from the date of its creation or the date when it last was in effect, whichever is later. That clause is the expensive one. A policy or a designation covering a service account that stays in effect for four years does not start its six-year clock at creation; it starts it at retirement. A decision made about an agent's access in 2026 can therefore sit inside a documentation obligation running into the middle of the following decade.

45 CFR 164.528(a)(1) gives an individual the right to an accounting of disclosures of their protected health information made in the six years prior to the request, and 164.528(b)(2) requires each entry to carry the date of the disclosure, the name of the entity or person who received the information, a brief description of what was disclosed, and a brief statement of the purpose. Read that against a shared service account. The entity must still be able to name the receiving party and the purpose, per record, up to six years later. When the caller was one of five systems and an agent, all presenting the same identifier, the log does not contain the answer, and no amount of forensic effort recovers a field that was never written.

Other clocks run alongside, on different objects and from different start events, which is the reason no single retention number can be assumed to govern. 42 CFR 482.24(b)(1), the Medicare condition of participation for hospital medical record services, requires that medical records be retained in their original or legally reproduced form for a period of at least five years — a federal floor, independent of the Security Rule's documentation clock, and running on the record rather than on the policy. In the life sciences, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails recording operator entries and actions that create, modify or delete electronic records, requires that audit trail documentation be retained for a period at least as long as that required for the subject electronic records, and requires that it be available for agency review and copying; paired with 21 CFR 312.62(c), which requires an investigator to retain records for two years following approval of a marketing application, or two years after the investigation is discontinued and FDA is notified, the audit horizon for an agent action in a clinical study routinely outlives the system that produced it.

And the reader at the far end of that horizon is frequently not an auditor. Under 31 U.S.C. 3731(b), a False Claims Act action may not be brought more than six years after the violation, or more than three years after the date on which material facts are known or reasonably should have been known by the official of the United States charged with responsibility to act, but in no event more than ten years after the date on which the violation is committed. The ten-year outer limit is the real design constraint. It sets the period over which an identity record and its audit trail must remain intelligible to a hostile reader who was not there, has no institutional memory, and is not obliged to accept a reconstruction.

This is what makes the identity question different in kind from the behaviour question. Behaviour can be monitored after the fact; you can add logging next quarter and be better off. Identity cannot be added retrospectively to actions already taken. Every day the shared account operates, it produces an irreducible quantity of unattributable history, and that history is the thing the retention clocks preserve.

What the field already knows, and the number nobody has published

The unusual feature of this problem is how much of the answer already exists in binding text, in other corners of the same sector, decades old.

21 CFR Part 11 has used the vocabulary of machine-credential revocation since 1997. Section 11.300(c) requires loss management procedures to electronically deauthorize lost, stolen, missing or otherwise potentially compromised tokens, cards and other devices that bear or generate identification code or password information. Section 11.300(b) requires that identification code and password issuances are periodically checked, recalled or revised. And 11.300(e) requires initial and periodic testing of such devices to ensure that they function properly and have not been altered. A tested revocation path is not a novel control being proposed for the agent era. In life sciences it is a regulation with nearly three decades of practice behind it, and the testing requirement in particular is the exact control that would convert a belief about revocation into a number.

The DEA's electronic prescribing rule supplies the other half: named triggers with a same-day deadline. 21 CFR 1311.125(d) requires an institutional practitioner to revoke a practitioner's signing permission on the date the occurrence is discovered, for the listed events; (d)(1) requires that access be terminated immediately upon receiving notification from the individual practitioner that an authentication factor has been lost, stolen or compromised; and (d)(2) to (d)(4) add expiry of DEA registration, termination or suspension of registration, and the practitioner no longer being authorised to use the application. Note the asymmetry in the same section: paragraphs (a) and (c) require two designated individuals for granting access and a second person's two-factor credential to enter the change — dual control on issuance, single-trigger immediacy on revocation.

Set those beside SMART's five-minute backend expiry and RFC 7009's candour, and the field's collective knowledge is fairly clear. Revocation must have named triggers. It must be tested rather than assumed. Its latency, not its existence, is the controlled variable. And for self-contained credentials, shortening the lifetime is the only mechanism that does not depend on a non-standardised interaction. None of that is contested. What is missing is measurement.

Specifically: I could not locate any primary published measurement of revocation propagation latency in healthcare — the elapsed time from a revocation request to actual enforcement at a FHIR resource server, and the rate at which revocation silently fails to take effect. ASTP/ONC mandates one hour in binding text. No conformance testing data, certification surveillance result, or vendor measurement of achieved latency against that bound surfaced in this pass. That is a binding numeric requirement with, as far as I can establish, no published evidence that anyone meets it. It is the open question these two essays sit on, and it is genuinely open.

The code below is not a remedy. It is the instrumentation that would let an organisation stop guessing at two of the quantities this essay says are undefined: which unit it is counting, and how long its revocation actually takes to bind. Both are diagnostics. Neither changes the account.

/** The five mutually incompatible things people mean by "machine identity". */
export type CountingBasis =
  | "directory-service-account"
  | "platform-workload-identity"
  | "vault-secret-object"
  | "credential-observed-in-traffic"
  | "credential-ever-issued";

export type CountedPopulation = {
  readonly basis: CountingBasis;
  /** Where the enumeration came from, so a second run can be compared to this one. */
  readonly source: string;
  /** Inclusive window for bases that are only defined over a window. */
  readonly window?: { readonly fromIso: string; readonly toIso: string };
  readonly total: number;
};

const WINDOWED: ReadonlySet<CountingBasis> = new Set([
  "credential-observed-in-traffic",
]);

export class UndefinedCountError extends Error {}

/** Produces a total that carries its own definition. Refuses to produce one that does not. */
export function count(
  basis: CountingBasis,
  source: string,
  identifiers: readonly string[],
  window?: { readonly fromIso: string; readonly toIso: string },
): CountedPopulation {
  if (source.trim() === "") {
    throw new UndefinedCountError("a count without a named source is not a measurement");
  }
  if (WINDOWED.has(basis) && window === undefined) {
    throw new UndefinedCountError(
      `basis "${basis}" is only defined over an observation window`,
    );
  }
  return { basis, source, window, total: new Set(identifiers).size };
}

/** Two populations are comparable only when they were counted the same way. */
export function comparable(a: CountedPopulation, b: CountedPopulation): boolean {
  return a.basis === b.basis;
}

export function ratioOrRefuse(
  numerator: CountedPopulation,
  denominator: CountedPopulation,
): number {
  if (!comparable(numerator, denominator)) {
    throw new UndefinedCountError(
      `refusing to divide a "${numerator.basis}" count by a "${denominator.basis}" count`,
    );
  }
  if (denominator.total === 0) throw new UndefinedCountError("empty denominator");
  return numerator.total / denominator.total;
}

The limits of this argument

Several things could be true that would weaken or defeat what is above, and they should be stated by me rather than found by someone else.

The definitional argument might be less consequential than it looks. It is possible that the plurality of counting bases matters for vendor marketing and hardly at all for practice, because a hospital that decides to inventory service accounts in its record system can pick one basis, apply it consistently, and get on with it. If that turns out to be the common experience, then the unit problem is a rhetorical problem about published figures rather than a structural obstacle to governance, and the essay overstates it. The claim I would defend is narrower: that comparing across organisations, or benchmarking against a published ratio, is meaningless without a declared basis.

The revocation-latency claim is an inference from specification text, not a measurement. I have argued that a successful revocation response bounds nothing at the resource server, and I have grounded that in RFC 7009's own implementation note. But the deployed reality could be much better than the specification's floor: many authorization servers and resource servers are operated by the same vendor and may well share state, making enforcement effectively immediate. A published measurement showing that certified servers routinely enforce revocation in seconds would substantially weaken this section. I would welcome it, and I could not find it.

The equilibrium argument is not universal. I have claimed that no sequence of individually rational review decisions retires the account. A single organisation with a strong platform team, a complete service catalogue and a genuine maintenance window would be a counter-example, and such organisations exist. The claim survives only in the form: under a no-downtime constraint with an incomplete dependency map, deferral is the rational choice at each review, and those two conditions are common rather than universal.

The regulatory reading could shift under me. The termination-procedures argument rests on an addressable specification, and the rulemaking that would change that has slipped rather than landed — final action is now reported as projected for July 2027. If it is finalised in the form proposed, the argument becomes stronger and part of this essay is out of date in the direction of understatement. If it is withdrawn or materially narrowed, the paragraph relying on the 24-hour proposal should be struck. Either way the reader should check the current status rather than take my word for it, which is why the status note is in the body rather than a footnote.

And the sector duties cited here are US instruments. I have written this in the vocabulary of the Code of Federal Regulations because that is where I could reach the primary text and confirm it at the level of the clause. A reader operating in India or the Gulf should take the mechanism rather than the citation: the structure of the problem — an undefined principal, a revocation path nobody has timed, and a documentation obligation that outlives the system — does not depend on which instrument attaches the duty.

What would falsify the central claim outright is a single artefact: a hospital that can produce, for an arbitrary read of a patient record eighteen months ago, the identity of the calling system, the human or committee that authorised its access, the scope that authorisation covered, and the date on which it was due to end — from records written at the time rather than reconstructed. If that artefact is common, the essay is describing an immaturity that the field has already passed. I have not seen it described in any primary source I can cite, which is not the same as knowing it does not exist.

What this points at

The teardown stops here deliberately. It is not difficult to write a paragraph beginning every credential should have a named owner and an expiry date, and such a paragraph would be true, useless, and indistinguishable from the advice that has already failed for seven years in the estate described at the top.

What the argument above does establish is the shape of any design that could work, and it is worth naming the constraints even without building against them.

• It has to work without a maintenance window, because the sector cannot take the system down and any design that assumes otherwise is inapplicable rather than merely difficult.
• It has to declare its unit, because a permission that is not a record with required fields cannot be tracked to closure and will be re-observed forever.
• It has to treat revocation latency, not revocation, as the controlled quantity — following the SMART Backend Services profile's own logic, and 21 CFR 11.300(e)'s requirement that such mechanisms be tested rather than assumed.
• It has to bind an owner to a principal and an expiry to an arrangement, because 45 CFR 164.308(a)(3)(ii)(C) attaches its duty to the ending of the arrangement, not to a directory change.
• And it has to produce evidence at the time of the action rather than reconstruct it afterwards, because 45 CFR 164.528(b)(2) asks for the recipient and the purpose per disclosure, and the ten-year outer limit at 31 U.S.C. 3731(b) sets how long that evidence has to stay readable.

Those five constraints are what the companion piece is written against. It is called Owned, expiring credentials for systems that cannot be taken down, it is published alongside this one, and it does the thing this essay refuses to do: it commits to a record, a lifecycle, a migration path that never requires the integration to stop, and a drill that turns the belief we could revoke this into a measured interval with a date on it.

Either way, the useful move is smaller and available immediately. Take the nearest thing your own estate has to the account in the opening section, and try to fill in five fields about it: who holds it, who authorised it, what scope that authorisation covered, when the arrangement it serves ended, and how long a revocation would take to bind. Not to fix it. Just to find out which of the five you can answer from records written at the time. Whatever that number turns out to be, it is a better measurement of the problem than any ratio in circulation, because it is one you took yourself.