Safeguard
Compliance•

What does zero trust for the cloud mean in practice?

Zero trust for the cloud means authenticating and authorizing each request, not trusting network location. Apply the NIST tenets to a multi cloud app.

Safeguard Security Team
4 min read

Zero trust for the cloud means no request is trusted because of where it comes from. Every access to a cloud resource is authenticated, authorized against policy and evaluated for device and identity state, session by session. NIST SP 800-207 gives the model, and cloud use is one of its named scenarios.

What does the model actually say?

NIST describes zero trust as an evolving set of paradigms that move defenses from static, network based perimeters to users, assets and resources. It assumes no implicit trust based on physical or network location, or on asset ownership. Authentication and authorization, for both subject and device, are discrete functions performed before a session to a resource is established. NIST presents it as a response to trends including remote users, bring your own device and cloud assets outside an enterprise owned network boundary.

CISA's Zero Trust Maturity Model organizes the work into five pillars and three cross-cutting capabilities, with traditional, initial, advanced and optimal stages for each pillar, as a roadmap federal agencies can use.

What are the tenets, in plain words?

NIST lists tenets that include these:

  1. All data sources and computing services are resources, including SaaS and small devices.
  2. All communication is secured regardless of network location. Trust is not granted because a device is on the enterprise network.
  3. Access is granted per session, with the least privilege needed, and access to one resource does not grant access to another.
  4. Access is decided by dynamic policy covering identity, application and device state, and possibly behavior and environment such as time and location.
  5. The enterprise monitors the integrity and security posture of all owned and associated assets. No asset is inherently trusted.

How does this look in a multi-cloud app?

NIST has a multi-cloud scenario. An enterprise with a local network uses two or more cloud providers, and sometimes an application in one cloud needs data held in another. NIST says that for performance and ease of management the application in Provider A should connect directly to the data source in Provider B rather than tunnel back through the enterprise network. The recommended approach is to place policy enforcement points at the access points of each application and data source, with the policy engine and administrator as services that can sit in either cloud or a third.

Constructed example: an orders service runs in Cloud A and reads customer records in Cloud B. The old design links the clouds through a flat VPN, so anything inside the VPN can reach the database. The zero trust design gives the orders service its own workload identity and has the database's access point check three things on each connection: is this identity valid, is it allowed to read only the tables it needs, and is the calling workload in a healthy state. A compromised test server in the same network gets no access because its identity has no grant.

What do you do first?

  1. Inventory resources, identities and flows. You cannot write per-resource policy for resources you have not listed.
  2. Strengthen identity. Use multifactor authentication for people and strong, short lived credentials for workloads, and remove long lived keys.
  3. Put enforcement at the resource. Require authentication at each service, not only at a network edge.
  4. Reduce standing privilege. Grant roles for specific tasks and review them.
  5. Add device and workload posture to access decisions where you can.
  6. Log every decision and monitor for unusual access.
  7. Reduce network trust gradually: segment, then tighten, then remove broad rules.

What are the traps?

NIST's own appendix notes that no single product provides all components, so expect to integrate several. It also lists threats to the architecture itself: subversion of the decision process, denial of service, stolen credentials and insider threat, and reliance on proprietary data formats. The decision point becomes a critical system, so make it highly available and protect it carefully.

Zero trust is also a program, not a purchase. Teams that buy a product labelled zero trust and keep flat networks and shared admin keys have not adopted it.

Quick check

Does zero trust mean no network security?

No. It means network location is not enough to grant access. Network controls such as segmentation still help, but each resource also checks identity and policy.

What is the first practical step?

Inventory your cloud resources, identities and the flows between them, then strengthen identity with multifactor authentication and short lived workload credentials.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.