Which control class prices out a provider's standing delegated access when patching and MFA have not?

## Name the invariant before naming a control Every technique has something it cannot substitute. Here it is one sentence: > **At the moment of use, a principal the provider controls must be able to hold privilege in the client tenant.** Everything else — which engineer, which workstation, which task, which day — is interchangeable. A control that does not attack that sentence is decoration, and a candidate who can state the sentence can derive the control list rather than recite it. ## Why the obvious controls miss **Patching.** There is no flaw in the chain. The credential is genuine, the role assignment is genuine, the action is the action the role exists to perform. A fully current estate is exactly as reachable as a neglected one. *We are fully patched* is a category error, not a partial answer. **MFA on your own administrators.** The principal is not in your directory. Hardening your own admin accounts changes nothing about a partner-directory identity that was granted a role in your tenant. **MFA on the provider's identity.** This one is worth being precise about, because it is half-right and candidates either over- or under-claim it. A second factor raises the cost of an outsider *stealing* the identity. It does nothing about *misuse by the legitimate holder*, and a push-approval factor is trivially satisfied by the engineer whose sign-in it is. Phishing-resistant methods such as FIDO2 or WebAuthn are still worth requiring — they close the theft route properly, which is the more common one — but they leave the invariant untouched. **Contractual assurance.** A questionnaire or an attestation changes who is answerable afterwards. It does not shorten the privilege by one second. ## The class that does bite: privilege lifetime and scope Five concrete moves, in rough order of effect: 1. **Remove standing membership.** Nobody holds the privileged role at rest. Elevation is *requested*, tied to a specific piece of work, *approved* by someone on the client side, and **expires automatically**. The expiry is the load-bearing part; an approval with no clock decays into standing access within a quarter. 2. **Grant the least sufficient role, not the highest one.** Most provider work does not need the top administrative role in the tenant. Two or three scoped roles usually cover the real workload, and the difference between those and full administration is the difference between a bad day and a total loss. 3. **Partition identities per client.** One identity spanning two hundred tenants is the multiplier. An identity entitled only in its assigned clients converts a single capture from an industry event into a handful of estates. 4. **Require phishing-resistant authentication on the claiming identity**, and require it to be a *dedicated* administrative identity — not the engineer's everyday account used for mail and browsing. 5. **Constrain where the claim can come from** — provider-managed devices, known network origins — so the entitlement is not usable from anywhere on earth by anyone holding the credential. All five are **preventive**. None of them requires anyone to notice anything, which matters here because the misuse looks like the identity doing its job. ## Why the misuse cannot be reasoned about as anomalous A privileged action by the provider's identity, in the tenant that provider administers, during working hours, is exactly what the identity exists for. There is no property of the action itself that separates the ordinary Tuesday from the intrusion. That is the structural reason the answer must be a *preventive* control class about what the identity is allowed to be, rather than a hope that the wrong use will look different from the right one. ## The honest residue You cannot get to zero, and claiming otherwise is a red flag of its own: - **Break-glass must exist.** A provider that cannot act during a genuine emergency is a provider that does not work. The design answer is a pre-approved emergency grant that self-activates with a hard expiry and has to be justified afterwards to a named client-side owner — not a permanent role kept for a rainy day. - **Some work genuinely needs high privilege.** Directory-wide changes exist. The goal is that they are rare, bounded and attributable, not that they never happen. - **You still depend on the provider's own identity hygiene** for the window during which the grant is live. ## The sentence that wins the question *You cannot remove the provider's need for privilege; you can remove its standing-ness, its breadth and its reach across clients.* Three properties, three controls, all preventive, all aimed squarely at the one thing the entry path cannot do without.