Why is a provider's delegated tenant administration a way into your estate with no exploit anywhere?

## What standing access actually is **Standing** access is privilege that exists before anyone needs it and survives after the work is finished. In a managed-service arrangement it usually takes one of two shapes, and the difference matters more than most candidates expect. 1. **An identity in your directory.** A shared remote-support account, or one account per provider engineer, created and governed by you. You can see it, reset it, require a second factor on it and disable it on a Friday afternoon. 2. **A delegated administration relationship.** The provider's engineers authenticate in the *provider's own* directory; a partner relationship grants principals from that directory a privileged role in your tenant. Your directory holds no user object for them. There is no password of theirs for you to reset, no second-factor method of theirs for you to strengthen, and no joiner/mover/leaver process of theirs that you run. You have imported another organisation's identity hygiene wholesale. Both shapes are ordinary and often sensible. A 90-person firm gets competent administration precisely because it rents it. The question an interviewer is asking is not whether the relationship is legitimate but what it costs you when the other end goes wrong. ## Why 'no exploit' is the load-bearing phrase Walk the chain and look for the broken thing. The credential presented is real. The second factor, if any, is satisfied by the person who owns it. The role assignment is one you or your predecessor approved. The administrative action performed is the action that role exists to perform. There is no memory-corruption bug, no unpatched service, no guessed password, no bypassed enrolment path, no misconfiguration. Every single step is an allowed action by a principal you authorised. That is why the reflex answer — *we are fully patched, so we are fine* — is a misclassification rather than a small error. Patching removes flaws. Here there is no flaw. The same reasoning kills two more reflexes: enforcing a second factor on **your** administrators does nothing to a principal that is not in your directory, and rotating **your** admin passwords does not touch a partner relationship at all. ## What the intruder inherits Whoever holds the provider's engineer identity does not inherit one estate. They inherit the provider's book of business, because the same identity is provisioned into every client the provider administers. The first estate costs whatever the provider cost; the second, third and two-hundredth cost a sign-in each. That is the aggregation that makes providers worth attacking at all, and it is why the loss of one small company's support account can turn into an industry-wide event. They also inherit *plausibility*. A privileged action by the provider's identity, on a weekday, in the tenant that provider administers, is exactly what the identity is for. The intruder does not have to look like anything other than an ordinary Tuesday. ## Where it sits in the frameworks ATT&CK places this under the **Initial Access** tactic as `T1199` **Trusted Relationship**: the adversary breaches or leverages an organisation that has access to the intended victim. It is deliberately distinct from: - `T1078` **Valid Accounts** (including `T1078.004` Cloud Accounts) — legitimate credentials for accounts in the victim's *own* environment. - `T1195` **Supply Chain Compromise** — trust arriving inside a delivered product, dependency or update rather than through a live administrative relationship. That separation is not pedantry. It tells you which control class applies. A valid-accounts problem is answered with credential strength and account lifecycle in your directory. A trusted-relationship problem is answered with the lifetime, scope and approval of privilege granted to somebody else's directory. ## The invariant the technique cannot substitute At the moment of use, **a principal the provider controls must be able to hold privilege in your tenant**. Everything else in the chain is negotiable; that is not. So the controls that actually bite are the ones that attack that sentence — make the privilege exist only during an approved engagement, make it the smallest role that does the job, and make the identity that claims it phishing-resistant and per-tenant rather than one identity spanning them all. ## What this does not mean It does not mean providers are careless or that outsourcing administration is a mistake. It means the relationship is a first-class entry path that no amount of work inside your own perimeter can close, and that the honest way to describe it in an interview is as authorised access being used by the wrong hands — not as a vulnerability.