What the model is, what it is not, and the first changes that matter in your cloud platform and in the products you build.
In short
Zero trust is a security model in which nothing is trusted because of where it sits on the network. Every request from a person, device or service is authenticated, authorised and checked against policy before it reaches data or an application. For cloud and product teams, that means strong identity, least privilege, segmented workloads and good logging, introduced in steps.
Zero trust has become a procurement phrase, which makes it hard to tell what a vendor, an auditor or your own architects mean when they use it. This explainer is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, platform leads and product owners. It separates the idea from the products sold under its name, shows what it changes in your cloud platform and in product design, and ends with a list of first steps you can take into a planning meeting.
What is zero trust?
Zero trust is a set of security principles that removes implicit trust based on network location and evaluates every access request on its own merits.
The reference definition comes from NIST SP 800-207, published in August 2020. It describes the approach as an evolving set of cybersecurity paradigms that move defences away from static, network-based perimeters and towards users, assets and resources. Four related terms are worth keeping apart:
- A zero trust architecture is an organisation's plan for applying these principles to its infrastructure and workflows. It is a design, not a box you buy.
- A policy decision point is the component that decides whether a request is allowed, based on identity, device health and context such as location or time.
- A policy enforcement point is the gateway, proxy or service that applies that decision and blocks or allows the connection.
- Least privilege is the rule that each identity gets only the access its task needs, for only as long as it needs it.
The practical consequence is simple to state and hard to implement. In the NIST model, the user and the device are authenticated and authorised before a session to a resource starts, and that check is repeated rather than assumed for the rest of the day. A request from the office network gets the same scrutiny as one from a hotel lobby.
What is the model not?
The model is not a product, not a VPN replacement and not a single control such as multi-factor authentication, even though each of those can be part of it.
Most confusion comes from vendors naming products after the model. This table separates the concept from the things it is often mixed up with:
Often confused with
What that actually is
How it relates to the model
Perimeter security and VPN
What that actually is
Trusts everything once a user is inside the network
How it relates to the model
The opposite assumption: location grants no trust
Zero trust network access (ZTNA)
What that actually is
A product category that brokers access to specific applications
How it relates to the model
One possible enforcement point, mainly for user-to-app access
Multi-factor authentication
What that actually is
A stronger way to prove identity at sign-in
How it relates to the model
A prerequisite, but says nothing about authorisation or devices
Microsegmentation
What that actually is
Splitting networks or workloads into small zones
How it relates to the model
Limits the blast radius; does not decide who gets access
A certificate or audit report
What that actually is
Evidence that controls existed at a point in time
How it relates to the model
Useful evidence, but the model is an ongoing way of operating
When a vendor names its product after the model, ask three questions: which access decisions does it make, which signals does it use, and what does it leave to you?
Which principles and pillars should you use?
The most practical reference is the CISA Zero Trust Maturity Model, which splits the work into five pillars and four maturity stages so you can assess progress area by area.
Version 2.0 of the CISA model, published in April 2023, uses these pillars:
- Identity: people and service accounts, how they authenticate and what they may do.
- Devices: laptops, phones, servers and connected products, and whether they are known and healthy.
- Networks: segmentation, encryption in transit and how traffic is routed.
- Applications and workloads: how software authenticates callers and enforces authorisation.
- Data: classification, encryption and access to the data itself.
Three capabilities cut across all pillars: visibility and analytics, automation and orchestration, and governance. Each pillar is scored from Traditional through Initial and Advanced to Optimal, which gives you an honest way to say "we are Advanced on identity and Traditional on data" instead of claiming the whole organisation is done.
The UK National Cyber Security Centre's zero trust architecture design principles say the same in plainer words, including "Know your architecture, including users, devices, services and data" and "Don't trust any network, including your own". Both models were written for public bodies, but nothing in them is specific to government, which is why they work as references for Nordic companies too.
What does the model change in cloud security?
In cloud security, the model mostly means treating identity as the main control, because cloud resources are reachable through public management APIs whatever your network looks like.
Cloud security (molnsäkerhet) is also a shared responsibility: the provider secures the platform, but identities, configuration and data remain yours. The changes that matter most in Azure, AWS or Google Cloud are:
- Human access: single sign-on, phishing-resistant multi-factor authentication for administrators, conditional access based on device and risk, and just-in-time elevation instead of standing admin rights.
- Workload identities: managed identities or workload identity federation instead of long-lived access keys and secrets stored in pipelines.
- Network controls: private endpoints and segmentation still matter, because they limit what an attacker can reach, but they are no longer the reason access is granted.
- Guardrails as code: landing-zone policies so that every new subscription or account inherits logging, encryption and access rules by default.
- Logging: central sign-in and audit logs, kept long enough and reviewed by someone with a named responsibility.
What does it mean for the products you build?
For product teams, the model means the software itself checks who is calling and what they may do at every service boundary, instead of trusting anything inside the cluster or the device network.
That has concrete design consequences:
- Service-to-service authentication. Internal services authenticate each other with mutual TLS or signed tokens, and they validate audience, issuer and expiry.
- Authorisation at the resource. The API checks that this user may read this object in this tenant. Hiding a button in the front end is not access control.
- Device identity. Connected products get their own credentials per device, with rotation and no shared default passwords. Updates are signed and verified.
- Secrets hygiene. No credentials in source code, container images or configuration files.
- Trust boundaries by design. Decide where data crosses from one level of trust to another during design, when moving a boundary costs a whiteboard session rather than a rewrite.
Where should you start?
Start with an inventory and with the identities that would do the most damage if compromised, then improve one pillar at a time; no organisation switches to the model in a single project.
There is also a regulatory reason to start. As of October 2026, recital 89 of the NIS2 directive (EU) 2022/2555 lists zero-trust principles among the basic cyber hygiene practices that essential and important entities should adopt. In Sweden the directive applies through the Cybersecurity Act (cybersäkerhetslagen), in force since 15 January 2026. The directive does not prescribe an architecture, but the model is a practical way to show that access control and segmentation are risk-based. For the obligations themselves, see NIS2 and the Swedish Cybersecurity Act: what to do.
A first-steps checklist:
- Inventory users, service accounts, devices, applications and data stores, each with a named owner.
- Protect privileged identities first: strong multi-factor authentication and no standing admin rights.
- Replace long-lived keys with managed or federated workload identities.
- Enforce authorisation in every API, including internal ones.
- Segment workloads and environments so that one compromised component cannot reach everything else.
- Centralise logs and decide who reviews which alerts, and how quickly.
- Score each pillar against the CISA stages and pick the next improvement per quarter.
Keep reading
From our work
Client Case: ZenseactHow Devies helped Zenseact make cybersecurity a natural part of developing safety-critical software for driver assistance and autonomous driving.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Is zero trust the same as ZTNA?
No. Zero trust network access (ZTNA) is a product category that gives users access to specific applications instead of a whole network, usually through a cloud broker. It can be one enforcement point in a zero trust architecture. The model itself is broader: it also covers device health, service-to-service authentication, authorisation inside applications, data protection and monitoring, none of which a ZTNA product handles on its own.
Do we have to replace our VPN to adopt zero trust?
Not immediately. The model changes why access is granted, not necessarily the tunnel. You can keep a VPN while adding strong identity, device checks and per-application authorisation behind it. Over time, many organisations move user access to application-level brokers and keep VPNs for a few administrative or legacy cases. Replace it when your identity and device controls can carry the decisions the network used to make.
Does NIS2 require zero trust?
Not as a specific architecture. As of October 2026, the NIS2 directive mentions zero-trust principles in recital 89 as an example of basic cyber hygiene, while its binding Article 21 requires risk-based measures such as access control, multi-factor authentication and network security. Applying the model is a practical way to meet several of those measures and to explain your choices to a supervisory authority.
How long does it take to implement zero trust?
It is a programme measured in years, not a project with an end date. Most organisations see the largest early gains within months from protecting privileged accounts, removing long-lived keys and enforcing authorisation in APIs. Use a maturity model such as the CISA one to score each pillar, choose the next step per quarter, and report progress as stage changes rather than as a percentage complete.
