One NOC seat reaches the firewall and sensor consoles of forty client estates — what does an intruder on that seat rewrite, and what does separating the seats cost?

## The arithmetic nobody does A managed-service provider sells one operations centre across many client estates. Each client bought a boundary; the provider's own management plane sits above all of them. Whatever a single operations seat can reach is one blast radius, and contracts do not subdivide it. Forty tenants administered from one seat is one control point governing forty policy planes — the exact inversion of what each client believed they were buying. This is a design question that interviews reach for because it is where the two halves of network defence meet: an adversary who lands anywhere in the provider's operations estate, and a price that lands on the provider's business model rather than on a device. ## What the intruder actually does from there Not evasion. Rewriting. In each tenant they can reach: add a permit, widen an object, place an inspection profile into log-only, or extend the access-control policy so a device is admitted. From the client's vantage this appears as ordinary provider activity by an account the client agreed to trust, which is the property that makes it so effective — the client's own monitoring is not looking for changes made by the party contracted to make changes. And the records that would show it are frequently held on the provider's side, by the same platform the intruder is standing in. Evidence produced by the party under question is worth very little to the client afterwards. ## The separation that does not separate The common and wrong answer is *"we hold per-client credentials in a vault, so the tenants are separated."* Per-client credentials separate **who can authenticate to each tenant**. They do not separate **what one compromised seat can reach**, because the seat retrieves them all, the vault serves them all, and one directory decides who the engineer is at every step. Credential separation without path and workstation separation is bookkeeping. What genuinely subdivides the blast radius: - **Per-tenant management path.** Reach terminates in the client's estate, and the client controls the termination — so removing the provider's reach is an act the client can perform without the provider's cooperation. - **Tenant-scoped identity the provider cannot mint unilaterally.** If the provider's directory alone can create an administrator in the client's console, the client's boundary is the provider's directory. - **Client-side records of console access and configuration change.** Held where the provider's console account cannot write, so the client can answer "what was changed, by whom, when" without asking the provider. - **Seat scoping.** Sessions to many tenants not held open simultaneously on one workstation; a compromised endpoint then reaches what it is currently working on, not the whole book. ## What that costs, stated plainly The efficiency of one operations centre reaching everything is the entire economic case for the model, so this separation is expensive in exactly the place that hurts: | What you add | Who pays, and how | | --- | --- | | Per-tenant path and termination | Build and run cost per client; onboarding a client stops being a template | | Tenant-scoped identity | A second lifecycle process per tenant, and client-side approval in the loop | | Seat scoping | Engineers handle fewer estates per shift; time-to-fix rises | | Client-side records | Integration work per client, and reconciliation when the two records disagree | A candidate who names the controls and not the costs has answered half the question. A provider that adopts all four for all forty tenants at once will not finish, which is why sequencing is the real senior content. ## How to sequence it Order by what a rewrite reaches, not by client size or by how loudly they ask: 1. Tenants where a policy rewrite touches regulated or safety-relevant flows, because the consequence of one change is not recoverable by rolling the change back. 2. Tenants whose console also governs the access-control policy — one rewrite there admits devices to segments, which converts a management-plane compromise into physical-network presence. 3. Tenants where the provider holds the only record of its own access, since those are the ones you cannot investigate honestly afterwards. 4. Everything else, on the standard onboarding path once the pattern is proven. ## Where this stops A client asking you to prove your operations centre cannot reach their consoles outside an agreed ticket is asking for an enforcement point on their side, not a policy statement on yours. Any assurance that the provider both enforces and evidences is an assurance about the provider's intentions. Design so the client can revoke you: that is the property that survives the day the provider is the thing that is compromised.