A castle-and-moat model fails because it assumes the people and systems inside the boundary can be trusted by default. That breaks down when trusted users mishandle data, devices move outside the perimeter, and cloud collaboration expands access paths. Zero Trust replaces that assumption with continuous verification and granular controls around each data interaction.
Why the Boundary Assumption Breaks in Practice
Castle-and-moat thinking works only when the perimeter is stable and internal access is inherently trustworthy. Modern data environments are the opposite: collaboration spans SaaS, cloud storage, APIs, remote endpoints, and partner integrations, so the “inside” is no longer a safe zone. Once access paths multiply, the perimeter becomes a coarse control that cannot express who should reach which data, from where, and under what conditions.
That is why Zero Trust is not just a network redesign, it is an access model for data movement. The control question shifts from “Are you inside the castle?” to “Should this request be allowed right now, for this resource, with this context?”
A useful way to think about the failure is that the model trusts location instead of behavior. In data-centric environments, location is a weak proxy for intent, device health, or entitlement quality, so it leaves too much implicit trust at exactly the point where decisions need to be explicit.
Why Data Access Becomes the Real Security Boundary
Data environments fail under castle-and-moat assumptions because the most important security decision is rarely whether a system is on the internal network. It is whether a user, application, or automated workflow should be allowed to read, copy, modify, export, or share a specific dataset at a specific moment. That decision has to follow the data wherever it moves.
This is where granular policy matters more than perimeter enforcement. Modern controls increasingly depend on continuous authentication signals, authorization scope, device posture, session context, and data handling rules, rather than a one-time network check. For teams operating in hybrid and cloud environments, the practical challenge is not whether the perimeter exists, but whether it still matches the actual trust boundary of the data.
NHIMG’s Ultimate Guide to Non-Human Identities also shows why broad access models fail operationally: 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts. Those are classic signs that access is being granted too widely for the level of control the environment actually needs.
Perimeter-only thinking also misses the fact that cloud collaboration expands the number of identities and systems that can reach data, including service accounts and API keys. Once those access paths exist, the protection problem is about entitlement, rotation, visibility, and revocation, not simply network placement.
Designing for Continuous Verification Instead of Default Trust
Zero Trust addresses the castle-and-moat failure by replacing implicit trust with repeated checks. The point is not to slow everything down, but to make each data interaction prove enough context to justify itself. That usually means combining identity, device, session, and data sensitivity signals so access is continuously re-evaluated rather than assumed after first entry.
Practically, this is strongest when paired with least-privilege access, short-lived sessions, and policies that narrow what each actor can do with the data after access is granted. In modern environments, the most resilient design is the one that assumes every session can become risky and every boundary can be crossed, then limits the blast radius when that happens.
For identity-heavy environments, the governance mechanics matter as much as the policy language. Coupang Signing Key Breach is a useful reminder that unrevoked credentials after offboarding can preserve access long after the original trust relationship should have ended, while The 2025 State of NHIs and Secrets in Cybersecurity reinforces how common excessive privileges, secrets sprawl, and weak rotation remain in real environments.
The key architectural shift is to treat every access path as conditional, observable, and revocable. If a control cannot answer those three questions, it is probably still behaving like a moat rather than a modern trust model.
Risk and Threat Considerations
Castle-and-moat models create a dangerous false sense of safety once users, devices, and integrations operate outside a single trusted perimeter. The main risks are overbroad access, weak revocation, and lateral movement after an initial foothold, because internal trust becomes an attacker advantage instead of a security control.
Failure mechanism: The model grants broad implicit trust after boundary entry, so compromised credentials, unmanaged devices, or overly permissive collaboration paths can be used to reach data without fresh verification or tight authorization checks.
Impact: A single compromised account or exposed integration can turn into wide data exposure, difficult-to-detect misuse, and slower containment because the environment was designed to trust internal activity too readily.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Directly supports limiting access by identity and context. |
| PR.DS — Data Security | Relevant because the question is about protecting data in modern environments. | |
| Recommendation — Apply PR.AC controls to enforce context-aware access and least privilege for data interactions. Apply PR.DS controls to protect data wherever it moves and is shared. | ||
| NIST Zero Trust (SP 800-207) | 3.4 — Policy Decision and Enforcement | Central to replacing perimeter trust with continuous policy decisions. |
| Recommendation — Use policy decision and enforcement points to re-evaluate each data request continuously. | ||
| CIS Controls v8 | 6 — Access Control Management | Supports managing access rights, revocation, and least privilege. |
| Recommendation — Enforce access control management to remove implicit trust and shrink data exposure. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Relevant where modern data access depends on service accounts and credentials. |
| Recommendation — Rotate and govern credentials so hidden access paths do not bypass data controls. | ||
Practitioner Guidance
What to verify: Test whether your highest-risk datasets are governed by request-level policy, not just network location. If a user can enter the environment but should still be blocked from certain records, the perimeter is not the control that matters.
Common mistake: Teams often modernise connectivity without modernising authorization. That leaves VPNs, SSO, and cloud access in place while the data plane still lacks meaningful segmentation, revocation discipline, and session-level control.
Practitioner takeaway: The right design goal is not “keep bad actors outside,” it is “make every data action justify itself,” because data environments fail when trust is granted too early and revoked too late.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
