ENTERPRISE SECURITY ARCHITECTURE

Closing the gaps

Six domains, seven conditions each. For every one: the paved road that removes it, the guardrail that holds it, and the state it converges on. None of the forty-two is a policy failure — each persists because the compliant option is harder than the alternative.

Domains
Six
Conditions
Forty-two
Sequencing rule
Build the road, then close the gate
Primary KPI
Adoption, not coverage
An optional layer on the diagram. Tool names are illustrative of the category, not a shortlist — the road and the guardrail are the architecture; the product is a replaceable implementation detail.

Identity

The worked example, carried in full: identity is what every other domain depends on.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Too many identities Federation at onboarding no unfederated app reaches production Long-lived credentials Secretless credential broker static access keys denied org-wide Inconsistent MFA Conditional access baseline legacy authentication protocols blocked Standing privileges JIT elevation with hard expiry permanent privileged assignment denied Manual provisioning and deprovisioning Joiner-mover-leaver automation access auto-disabled on termination event Weak workload identity Workload identity federation shared service secrets refused at deploy Limited access visibility Entitlement inventory and graph access decision logging is not optional TARGET SECURITY STATE Identity is the control plane One authoritative identity per person and per workload Every credential short-lived, attested and rotated by default Phishing-resistant MFA enforced at the provider, not per app No standing production privilege — elevation granted, then expires Joiner-mover-leaver reconciled from the system of record “Who can reach this?” answered from one inventory, in minutes Every access decision logged, attributable and reviewable Reached in Phase 3. Sustained — not merely achieved — in Phase 4, when the assurance layer proves it without anyone being asked.
Why each condition persists, and the proof it is gone

Why each condition persists, what removes it, and the number that proves it is gone.

Condition todayWhy it persistsProof it is gone
Too many identitiesPhase 1–2Applications were onboarded with their own local account stores; nothing ever required federation.Distinct identity stores; % of applications federated; orphaned local accounts.
Long-lived credentialsPhase 2–3Static keys are the only thing that works reliably in pipelines, because no broker exists.Median credential lifetime; static keys over 90 days; secrets found in repositories.
Inconsistent MFAPhase 1–2MFA was applied per application, and legacy protocols bypass whatever was configured.% phishing-resistant authentications; legacy auth attempts; applications outside the baseline.
Standing privilegesPhase 2–3Elevation is slow when it is needed, so temporary admin was granted and never revisited.Standing privileged accounts; median elevation duration; break-glass reviews.
Manual provisioning and deprovisioningPhase 2–3No authoritative feed from the system of record: access is granted by ticket, removed from memory.Termination-to-revocation time; dormant accounts; recertification rate.
Weak workload identityPhase 2–3Services use shared secrets because no attested workload identity exists to use instead.% workloads on federated identity; shared service accounts; median token lifetime.
Limited access visibilityPhase 3–4Entitlements live inside each system, so answering who can reach what takes days.% entitlements in the inventory; time to answer; over-permissive findings.

The pattern to notice

Not one of these seven is solved by writing a stronger policy, and several have almost certainly had a policy written about them already. Each persists because the compliant option is harder than the non-compliant one — no broker, no elevation workflow, no attested workload identity, no inventory. That is precisely what the paved road layer exists to fix, which is why identity gets the first two roads in Phase 1 rather than the first two guardrails.

Where a condition has survived a policy, it is a supply problem. Build the road, then close the gate behind it.

Network

Everyone knows the flat segment exists. It survives because closing it breaks traffic that has no other path.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Flat internal networks Segment-aware network modules east-west traffic default-deny VPN as the access path Self-service ZTNA onboarding legacy VPN routes retired on schedule Uncontrolled egress Managed egress proxy with allow-lists no unmanaged internet egress path Firewall rules by ticket Policy sets as code, reviewed in pipeline manual console changes reverted Unknown internet exposure Attack surface feed mapped to owners public ingress denied by default OT, clinical and lab estates unsegmented Assured enclave reference build cross-enclave traffic brokered only Third-party site-to-site tunnels Partner access through the same broker no new site-to-site tunnels approved TARGET SECURITY STATE Position confers nothing Application access brokered by identity, never by network location East-west traffic default-deny inside a defined segment model Egress leaves only through managed, allow-listed paths Network policy is code, reviewed and versioned like any change No internet-exposed asset without a named owner OT, clinical and lab estates isolated in assured enclaves Partner access uses the same broker as employee access Reached in Phase 3 for the corporate and cloud estate. Constrained estates — OT, clinical, lab — land one phase later, by design.
Why each condition persists, and the proof it is gone

Read the middle column as a work queue.

Condition todayWhy it persistsProof it is gone
Flat internal networksPhase 1–3Segmentation was inherited rather than designed, and no module places a workload correctly.Legacy segments remaining; % workloads in a defined segment; denied east-west attempts.
VPN as the access pathPhase 1–3The VPN works for everything, so nothing pushes an application onto a better path.% applications behind ZTNA; concurrent VPN sessions; apps still needing full network access.
Uncontrolled egressPhase 2–3Open egress is the cloud default, and closing it breaks builds until a proxy path exists.% workloads through the proxy; unauthorised egress attempts; destinations off the allow-list.
Firewall rules by ticketPhase 2–3Change outruns the review queue, so rules accumulate and nobody removes them.% rules managed as code; rule age and unused rules; time to complete a change.
Unknown internet exposurePhase 1–2Exposure is created faster than it is inventoried, and findings arrive without an owner.Exposed assets with an owner; exposure-to-detection time; unexpected exposures per month.
OT, clinical and lab estates unsegmentedPhase 3–4These estates carry devices that cannot be patched, so the network was left alone.% estates inside an enclave; brokered versus direct flows; unmanaged devices per enclave.
Third-party site-to-site tunnelsPhase 3Each partner tunnel was built at speed and outlived the project that justified it.Tunnels with an owner and expiry; partner sessions brokered; tunnels retired per quarter.

Cloud

The domain where the paved-road argument is easiest to win: the console was simply faster than the platform.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Ungoverned accounts and subscriptions Account vending machine accounts created only through vending Click-built infrastructure Terraform module library console write access removed in production Configuration drift goes unnoticed Drift detection with automatic revert reconciliation runs on schedule Inconsistent logging Central logging wired in at vending logging cannot be disabled in production Public exposure by default Private-by-default baselines and modules public access denied at the organisation root Unowned and untagged resources Tagging applied by the provisioning module mandatory tags enforced at creation Inconsistent key management Key custody pattern with CMK modules unencrypted resources denied TARGET SECURITY STATE The platform is the baseline Every workload lands in a governed account with inherited controls Infrastructure is derived from modules, not assembled by hand Drift is detected and reverted without a human in the loop Logging, encryption and key custody are set before first use Nothing is public unless a decision deliberately made it so Every resource has an owner, an environment and a classification Posture is continuous evidence, not a quarterly screenshot Reached in Phase 3. From Phase 4 the same posture data serves as continuous audit evidence rather than a quarterly collection exercise.
Why each condition persists, and the proof it is gone

Note how many resolve at account creation rather than at deployment. That is where the leverage is.

Condition todayWhy it persistsProof it is gone
Ungoverned accounts and subscriptionsPhase 1–2Teams needed environments faster than governance could supply them.% accounts through vending; unmanaged accounts; time to a governed environment.
Click-built infrastructurePhase 2–3The console is the fastest route to something working, and no module fit the need.% resources from approved modules; console writes in production; adoption per team.
Configuration drift goes unnoticedPhase 2–3State is compared only when something breaks or an audit asks.Drift mean time to repair; resources diverged from intent; auto-reverted versus manual.
Inconsistent loggingPhase 1–2Logging is configured per project, at the end, on the team's own budget.Log coverage against the inventory; accounts with gaps; attempts to disable logging.
Public exposure by defaultPhase 2–3Provider defaults favour reachability, and the demonstration became production.Publicly reachable resources; policy denials per week; creation-to-detection time.
Unowned and untagged resourcesPhase 1–2Tags are a convention, and whoever created the resource has moved on.% resources fully tagged; unowned spend; orphaned resources.
Inconsistent key managementPhase 2–3Encryption is decided per service, with no default pattern for custody or rotation.% stores on approved key patterns; rotation compliance; resources on default keys.

AppSec

One root cause: security was applied to the artefact after it was built rather than designed into how it gets built.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Every team has its own pipeline Golden pipeline templates per language only approved pipelines can deploy Unknown third-party components SBOM produced as a build artefact builds without an SBOM cannot promote Unsigned artefacts in production Signing and attestation service unsigned artefacts rejected at deploy Secrets in source Managed secrets with pre-commit scanning a detected secret blocks the merge Threat modelling done ad hoc Lightweight model in the design workflow required for externally reachable services Vulnerability backlog without an SLA Triage service routing by severity severity thresholds break the build No disclosure path PSIRT intake and coordinated disclosure disclosure SLA tracked as a release criterion TARGET SECURITY STATE Trust the build, not the scan Every deployable artefact comes from a hardened, approved pipeline Contents are known: an SBOM is produced and kept at build time Provenance is verified at deploy, not asserted in a document Secrets never enter source control or an image layer New externally reachable services carry a threat model Remediation runs to a published SLA by severity Disclosure has a front door and a clock that is met Reached in Phase 3. Phase 4 verifies provenance at deploy time, so the claim is checked by the platform rather than asserted in a document.
Why each condition persists, and the proof it is gone

The section that carries the most external weight in a regulated product estate.

Condition todayWhy it persistsProof it is gone
Every team has its own pipelinePhase 1–2Pipelines grew with each team, and no shared one was ever worth migrating to.% builds on golden pipelines; pipeline variants in use; time to first deploy.
Unknown third-party componentsPhase 1–2Dependency inventory was collected by hand for an audit and went stale immediately.% releases with a current SBOM; time to answer an exposure question; unknown components.
Unsigned artefacts in productionPhase 2–3Signing needs key custody and a deploy-time check; neither existed.% artefacts verified at deploy; failed verifications; unsigned base images.
Secrets in sourcePhase 1–2A secret in a file is the only thing that works the same on a laptop and in production.Secrets per thousand commits; time to rotate a leaked secret; repositories with history.
Threat modelling done ad hocPhase 2–3Threat modelling needed a security person in the room, so it happened only on request.% new services with a model; findings at design versus test; effort per service.
Vulnerability backlog without an SLAPhase 2–3Every scanner reports into one queue with no owner.Mean time to remediate by severity; backlog age; findings with an owner.
No disclosure pathPhase 2–3Reports arrive wherever a researcher can reach, with no clock, owner or advisory route.Report to acknowledgement and to advisory; reports via the published channel; advisories on time.

Data

Most policy written, least changed — because classification without a mechanism is a document.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Unknown sensitive data locations DSPM discovery across all estates classification tag required at creation Classification exists on paper only Handling matrix wired into storage modules controls derived from the tag, not negotiated Production copies in lower environments Subsetting and de-identification service production data denied in non-production Keys managed inconsistently Key custody pattern with rotation automation unencrypted or default-key stores denied Over-permissive data access Access request workflow on a data model broad grants blocked and recertified No retention or deletion Retention policy as code, set at creation stores without a retention policy denied Residency handled per project Region-constrained storage modules residency enforced by region allow-list TARGET SECURITY STATE Controls follow the classification Sensitive data is found where it lives, not where it was declared Handling is derived from classification, not negotiated per project Non-production never holds production data Encryption and key custody set at creation, rotated on schedule Access is requested, granted narrowly and recertified Retention and deletion are enforced by the platform Residency is a property of the module, not a project promise Reached in Phase 3, except residency and defensible deletion, which land in Phase 4 once lineage is complete enough to prove them.
Why each condition persists, and the proof it is gone

Unusually honest middle column: several of these persist because the non-compliant option solves a real problem.

Condition todayWhy it persistsProof it is gone
Unknown sensitive data locationsPhase 1–2The inventory was built from what teams declared, not from what exists.% stores classified; shadow stores found per quarter; unclassified stores.
Classification exists on paper onlyPhase 2–3The scheme was published without a mechanism to apply it.% stores whose controls match their class; open exceptions; misclassified stores.
Production copies in lower environmentsPhase 2–3Realistic test data is a real need, and copying production is what has always worked.Non-production stores holding production data; % test data from the service; copies detected.
Keys managed inconsistentlyPhase 2–3Key decisions were made per service; rotation needs coordination nobody scheduled.Rotation compliance; stores on required key types; keys past rotation age.
Over-permissive data accessPhase 2–3Broad access unblocked analytics, and there is no easy way to ask for less.Over-permissive findings by age; % grants scoped to a role; recertification rate.
No retention or deletionPhase 3Deleting feels riskier than keeping, and nobody owns the cost of keeping.% stores with enforced retention; data held past its period; deletions executed.
Residency handled per projectPhase 3–4Residency arrives as a contract clause late, and is solved once, by hand.% regulated data in permitted regions; cross-border transfers; open exceptions.

AI

The youngest domain, and the only one where the gap is still opening faster than it closes.

CURRENT STATE PAVED ROAD · GUARDRAIL WHERE IT LANDS Shadow AI use Approved model catalogue and gateway SDK direct provider calls blocked at egress No inventory of models and agents Registration in the catalogue at build unregistered models cannot reach production Agents share human credentials Agent identity issuance module agent actions require a scoped machine identity Unbounded tool access Tool mediation with declared permissions high-impact calls need approval, and expire Sensitive data reaching context windows Retrieval with tenant and class isolation restricted data classes denied at retrieval Release without evaluation Evaluation harness and red-team playbook release blocked without evaluation evidence Agent actions not auditable Audit library capturing prompt, call, actor logging is not optional on the gateway path TARGET SECURITY STATE Autonomy is granted, scoped, revocable Every model call passes through a mediated, logged path Models and agents are registered before they reach production Each agent holds a scoped identity of its own, never a human's Tool access is declared, bounded and time-limited Retrieval cannot cross a classification or tenant boundary Release requires evaluation evidence, not confidence Every agent action is attributable, replayable and reviewable Reached in Phase 3 for models, Phase 4 for agents — the audit trail for autonomous action is the hardest and last piece to complete.
Why each condition persists, and the proof it is gone

Every condition here has an analogue in identity or AppSec. That is the argument for treating AI as a domain, not a novelty.

Condition todayWhy it persistsProof it is gone
Shadow AI usePhase 1–2The tools are useful and one tab away. Blocking without a sanctioned path moves usage off-network.% AI traffic through the gateway; direct provider calls blocked; sanctioned adoption.
No inventory of models and agentsPhase 1–2Models sit inside applications, so nothing in the delivery process asks about them.Registered versus discovered; time to answer which systems use a model; blocked deployments.
Agents share human credentialsPhase 2–3Borrowing a token was the fastest way to make an agent work.% agents with their own identity; actions on human credentials; revocation time.
Unbounded tool accessPhase 2–3Broad permissions granted during development are what ships.Median permissions per agent; entitlements past expiry; approvals required versus automatic.
Sensitive data reaching context windowsPhase 2–3Indexes were built for usefulness first, with permissions resolved later.Retrieval denials by classification; indexes with tenant isolation; sensitive data in prompt logs.
Release without evaluationPhase 2–3No agreed definition of good enough, so release rests on a demonstration.% releases with evaluation evidence; regressions caught pre-release; red-team findings closed.
Agent actions not auditablePhase 3–4Logging was designed for requests, not for chains of reasoning and tool calls.% actions with a replayable trace; time to reconstruct an incident; audit gaps.