Why does zero trust break down if organisations only verify identity, device posture, and application access?

Zero trust breaks down when trust stops at access approval. A user may be authenticated and authorised to open a record, yet still be able to print it, copy it into an email, screenshot it, or expose it during screen sharing. That gap lets sensitive data escape the original control boundary and undermines least privilege in practice.

Why access approval is not the same as zero trust

Zero trust only works when verification continues after the login and the allow decision. If the organisation stops at identity, device posture, and application access, it has only controlled entry to the system, not the actions taken inside it. That leaves a large gap between “permitted to open” and “permitted to do,” which is where sensitive data often escapes.

The practical failure is that access controls usually govern a session boundary, while real exposure happens at the content boundary. A user can be legitimate and still move data out of the approved workflow through printing, copying, screenshots, local downloads, forwarding, or screen sharing. Zero trust has to account for those post-access actions, not just the gate at the front door.

For the underlying model, NIST SP 800-207 Zero Trust Architecture treats trust as something that must be continuously evaluated rather than assumed after initial authentication. NHI Mgmt Group’s Ultimate Guide to NHIs also reinforces that zero trust depends on more than a valid identity check when credentials, privilege, and lifecycle controls are part of the enforcement chain.

Where the control boundary fails in practice

Breaking zero trust into “verify identity, verify device, allow app” is attractive because it is easy to implement and easy to report on. The problem is that it treats the application as the final control point, when the application may still expose copy/paste, export, download, print, sync, or sharing functions. Once the data is rendered on a trusted screen, the sensitive object can leave the original boundary in a way the access policy never sees.

This is why least privilege must be defined by effective capability, not just by successful authentication. A session that can read a record but can also export thousands of records, paste them into another channel, or display them over shared screens is not truly least privilege. The control has authenticated the actor, but it has not constrained the actor’s usable reach over the data.

That distinction matters for privileged workflows, regulated information, and any environment where the same record can be consumed, transformed, and retransmitted. A strong zero trust design usually needs application controls, data controls, session controls, and monitoring working together, not a single allow decision at sign-in. The NIST AI Risk Management Framework is useful here as a governance lens when organisations are deciding how much post-access freedom to permit in automation-heavy environments, and the OWASP ASVS provides a complementary view of application-side access control and session handling.

Risk and Threat Considerations

When organisations only check who signed in and whether the device looks trusted, they create a false sense of containment. The risk is data exfiltration through ordinary user behaviour, not necessarily through a dramatic exploit. The same weakness also helps insiders and compromised accounts because once the session is open, the attacker can use normal features to move data out without breaking the original authentication control.

Failure mechanism: The policy authorises access to a record or application, but it does not constrain downstream actions such as export, copying, printing, forwarding, or screen capture. That lets the protected data escape the original policy boundary while the session still appears legitimate.

Impact: Sensitive information can spread into email, chat, screenshots, local files, or shared screens, which increases breach scope, weakens auditability, and turns a narrow access decision into a broader confidentiality failure.

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-4 — Access Permissions and Authorizations	Controls who can do what after login, which is central to limiting post-access data exposure.
Recommendation — Restrict permissions to the minimum actions needed and review whether data-export paths are also constrained.
NIST Zero Trust (SP 800-207)	JAM — Policy Enforcement and Continuous Evaluation	Zero trust depends on ongoing enforcement, not a one-time allow decision at authentication.
Recommendation — Continuously evaluate session context and enforce policy on each access request and data action.
OWASP Non-Human Identity Top 10	NHI-03 — Least Privilege and Access Scope	Over-broad access scope breaks least privilege even when identity is verified.
	NHI-06 — Secrets and Credential Lifecycle	Access decisions are only durable when credentials and delegated access are tightly governed across their lifecycle.
Recommendation — Scope each identity to the smallest effective action set, including export, sharing and delegation paths. Rotate and revoke credentials quickly so stale access cannot outlive the intended trust boundary.
CIS Controls v8	6.3 — Access Rights Management	Prescriptive access-rights governance is needed to limit what authorised users can do with sensitive data.
Recommendation — Review and remove unnecessary rights, especially permissions that allow export, forwarding or bulk extraction.

Practitioner Guidance

What to prioritise: Treat “allowed to open” as only the first control point. The next question is whether the session can still leak data through export, copy, print, screenshot, or sharing paths that your access policy does not govern.

What to verify: Confirm that the application, data layer, and session controls all reflect the same policy intent. If users can see highly sensitive content, check whether they can also move it into email, messaging, local storage, or unmanaged collaboration tools without an additional control decision.

Common mistake: Teams often measure zero trust success by login strength and device compliance alone. That misses the more important test, whether the user can only do the minimum required action with the data after access has been granted.

Practitioner takeaway: Zero trust fails when identity becomes the end of the story; the model is only credible when access is continuously constrained at the data and action level, not just at the login page.