Isolation surface size.

CRC's Consolidate pillar tells you to reduce the number of distinct application edges your organization carries. This page answers the next question: once you've consolidated, how big should each resulting boundary be?

CRC Pillar 1 — Consolidate. Every external AI inference endpoint is named, certificate-pinned, logged, and formally attested. Wide trust boundaries make new integrations feel cheap — until the accumulated privilege becomes visible. Isolation surface size is the metric that makes it visible before the breach, not after.

Attack surface vs. isolation surface.

Attack surface counts exposed entry points — open ports, unpatched services, API credentials, every SaaS application wired into a workflow. It asks where an intruder gets in. That's a necessary question, but not a sufficient one.

Isolation surface size picks up where that question leaves off. Once a credential is compromised or a certificate's signing key is stolen — through any door, by any method — how much privilege, how many principals, how much organizational value sat behind that one boundary? A system can have a vanishingly small attack surface and still have a vast isolation surface, if everything inside the perimeter shares one signing key.

A master key protecting more isn't a busier key. It's a more valuable one to steal.

The causal direction runs from surface to edges, not the other way around. A wide isolation surface removes the one thing that would otherwise force a decision: when everything already shares the same certificate, a new SaaS connection just gets bolted on, because nothing in the architecture ever asks whether it belongs there or needs a boundary of its own. Surface width is not a side effect of edge count. It is the thing that determines how many edges an organization ends up tolerating — because wide trust boundaries make new integrations feel cheap until the accumulated privilege becomes visible.


A worked example: ServiceNow + Salesforce.

A typical mid-enterprise running ServiceNow and Salesforce under the same identity domain — the default configuration for most SSO deployments — combines service accounts, integration users, admin credentials, API keys for connected systems, RPA agents, and automation bots across both platforms. Honest principal count including service accounts: 400–600 distinct privileged identities, all sharing one effective trust boundary through a single IdP credential.

Run those parameters through the formula below at conservative assumptions calibrated to publicly available breach probability data and typical SaaS privilege scope:

ServiceNow + Salesforce — shared SSO domain
T=500   p=0.008   v̄=25   c_r=60   c_c=30   f=0.35
S* = √[(60 + 30·0.35) / (0.008·25)] = √[352.5] ≈ 19
Optimal: ~19 principals per certificate → ~26 certificates needed
Current: 500 under one certificate → surface ~26× larger than optimal

Running 500 principals under a single SSO boundary puts total cost roughly 4.5× above the curve's minimum. The formula doesn't say the current configuration is inoperable — it says you are carrying roughly 4.5× more risk-adjusted cost than the same environment, properly partitioned, would require. Use the calculator below to load this profile and adjust it to your own numbers.


The formula.

Three forces trade off. Safety cost rises with surface size — a certificate that covers more principals is more valuable to compromise. Complexity and convenience costs fall — fewer, larger certificates mean less provisioning overhead and fewer legitimate workflows hitting a boundary. The curve has an interior minimum.

Total cost as a function of surface size
Cost(S) = p··S·T + (c_r + c_c·f)·(T/S)
Optimal surface size
S* = √[ (c_r + c_c·f) / (p·) ]
SymbolMeaning
SIsolation surface size — principals per certificate
TTotal principal population across the deployment
pPer-principal compromise probability
Average privilege / value per principal
c_rFixed cost of issuing and maintaining one certificate boundary
c_cConvenience cost per cross-boundary workflow
fFraction of workflows that cross a boundary

T cancels out of S* — the optimal surface size is independent of total population. A fifty-principal team and a fifty-thousand-principal enterprise should target the same S*. The enterprise just needs more certificates at that size, not bigger ones.


Try it.

Adjust the inputs. The optimal surface size, certificates needed, and cost multiple update live. Load a preset profile or add your own.

Total principals (T) 500
All privileged identities — humans, service accounts, API keys, agents
Compromise probability (p) 0.008
Likelihood any one principal's credential is compromised in the period
Average privilege / value (v̄) 25
Relative value of what one principal can reach or authorize
Cost per certificate boundary (c_r) 60
Provisioning, cert issuance, schema, ongoing maintenance per boundary
Convenience cost coefficient (c_c) 30
Friction when a legitimate workflow can't cross a boundary
Cross-boundary frequency (f) 0.35
Share of workflows that need to cross a certificate boundary
Optimal surface size (S*)
principals per certificate
Certificates needed (T / S*)
certificate boundaries
ISS — Isolation Surface Score
100 = optimally partitioned  ·  lower = cost curve is past its minimum

ISS (Isolation Surface Score) — 100 × Cost(S*) / Cost(T). A score of 100 means the current environment is already sized at its own cost minimum. A score of 50 means the current configuration costs roughly twice what an optimally partitioned deployment of the same scale would require. The score is derived entirely from the formula inputs above — it is an efficiency indicator, not a compliance certification.

Current surface is significantly wider than optimal. At × S*, the cost curve is well past its minimum — your organization is carrying substantially more risk-adjusted cost than an optimally partitioned deployment of the same size would require. The CRC Consolidate pillar is designed to address exactly this condition.

Compare real-world profiles.

Six illustrative configurations, including the ServiceNow + Salesforce shared-domain example. Cost per principal factors out population size for a fair comparison across scales. ISS (Isolation Surface Score) — 100 × Cost(S*) / Cost(T) — shows how close each environment is to its own cost minimum: 100 is fully optimized, lower scores indicate a surface wider than optimal. Load any row to set the calculator to that profile.

EnvironmentS*CertsCost / principalTotal costISS
These are illustrative profiles, not measurements. The interior-minimum shape of the cost curve is the falsifiable claim. Every constant — p, v̄, c_r, c_c, f — is an assumption pending real deployment telemetry. The ServiceNow + Salesforce numbers use publicly available breach probability baselines and are conservative estimates, not vendor claims. Adjust to your own environment using the calculator above.

Read the CRC Standard Score your stack Chandra implementation ↗

General Reasoning, Inc. · Birmingham, Alabama · MIT License · 2026
Enterprise inquiries: inquiries@genreason.com