intellimetrics Learning
Zero Trust Implementation Module 6 · Making It Stick

Externalize Every Trust Anchor

Last reviewed

Advanced

What you'll learn

~15 min
  • Treat login authorities, directory hosts, and tenant IDs as configuration, never constants
  • Write portability requirements as symptom→consequence gaps with observable acceptance criteria
  • Fence temporary workarounds with expiry dates so they cannot calcify into architecture

The assumption hiding in your source code

Every app this training secured authenticates against something: a login authority, a directory graph, a tenant. Now the question nobody asks until it hurts: where do those endpoints live in your code? In most estates the honest answer is: compiled in. A hardcoded login URL here, a public-cloud graph host there, a tenant ID in a config committed three years ago. It all works perfectly — until the day the app must run somewhere else: a government/sovereign cloud region (different login authority, different graph host, same vendor), a partner’s tenant, or an air-gapped enclave where the endpoints aren’t even known until deployment.

For Meridian this is concrete: the state regulator wants the outage-reporting stack deployable in the state’s sovereign cloud enclave. And the Zero Trust framing is exact — this is tenet 2 applied to your own infrastructure assumptions: an app that trusts “the login host is login.example.com” has hardcoded a claim about its environment, precisely the kind of implicit trust the architecture forbids. The identity pattern (verify explicitly, per-session, strong auth) must survive relocation; only the anchors may change.

The spec shape that fixes it

The reusable artifact — modeled on a real multi-cloud identity-portability spec — has a structure worth copying for any portability problem:

1. ENVIRONMENT MATRIX     every target environment × its anchors: login
                          authority, directory/graph host, tenant source -
                          with the air-gapped column marked "declared per-
                          deployment" (values arrive WITH the deployment,
                          not before)
2. GAP LIST               written symptom → consequence, never as blame:
                          "login host hardcoded → app cannot authenticate
                          in any sovereign region"
                          "single-tenant assumption in token validation →
                          partner deployment impossible"
3. NUMBERED REQUIREMENTS  each gap pairs to a source-level requirement
                          ("R3: authority, graph host, and tenant resolve
                          from configuration at startup")
4. ACCEPTANCE CRITERIA    observable outcomes - including the NEGATIVE one
                          that does the real work: "grep of the built
                          artifact finds NO endpoint hostnames" - an
                          assertable, CI-able property
5. WORKAROUND FENCE       the temporary hack quarantined in its own trailing
                          section WITH AN EXPIRY - never mixed into the
                          requirements it contradicts

Two of those deserve underlining. The negative acceptance criterion is this training’s verify-by-denial (5.3) applied to code: “no compiled endpoint” is provable mechanically, forever, in CI — where “endpoints are configurable” is a claim someone has to believe. And the workaround fence exists because every portability effort ships one ugly bridge (“env var override just for the pilot”) — fenced with an expiry it’s engineering; mixed into the spec it’s the new architecture, and Lesson 1.3’s expiring-exception rule applies word for word.

Run the portability audit on this codebase: find every compiled trust
anchor (login/token endpoints, graph hosts, tenant IDs, issuer strings,
audience values, vault URIs) - source, config defaults, IaC, and pipeline
variables. Output the five-section spec above: matrix for [commercial /
sovereign / air-gapped], symptom→consequence gaps with file:line evidence,
numbered requirements, acceptance criteria incl. the negative grep, and a
fenced list of any workaround we'll tolerate, each with owner + expiry.
Then add the CI job implementing the negative criterion.

The same audit, run estate-wide, catches the non-code anchors too — Lesson 5.1’s workspace-ID-pasted-in-five-files finding was this disease in IaC form, and the fix is the same: resolve by lookup, assert the absence of literals.

🔍Air-gap changes the philosophy, not just the values

The sovereign columns of the matrix teach a subtle lesson: in the air-gapped enclave the anchors are not merely different — they are UNKNOWABLE at build time. That forces the healthiest possible design: the artifact must be complete without them (Cloud Modernization’s vendored, self-contained golden paths), and identity must bootstrap from what the enclave provides (per Lesson 3.4’s brokered patterns). An app that passes THAT bar is trivially portable everywhere easier — which is why regulated-environment discipline, annoying as it is, tends to produce the best-factored systems in the portfolio.

KNOWLEDGE CHECK

Mid-audit, a developer pushes back: 'We're a single-tenant shop on one cloud — externalizing every endpoint is speculative generality for a sovereign deployment that may never happen. YAGNI.' What's the strongest honest answer?

Key takeaway

Login authorities, graph hosts, and tenant identities are configuration, never constants — audited via the five-section spec, enforced by a negative criterion CI can hold forever, with every workaround fenced and expiring. The identity architecture survives relocation because nothing about its location was ever compiled in. Next: making the safe path the one that requires no discipline at all.

Search lessons