Zero Trust in practice: how to implement a Zero Trust architecture in your company

What Zero Trust is and the "never trust, always verify" principle

Zero Trust is a security architecture model that eliminates the implicit trust granted to users, devices, or traffic merely because they are inside the corporate network. Instead of assuming that everything within the perimeter is safe, every access request is treated as potentially hostile and must be authenticated, authorized, and validated before being allowed. NIST SP 800-207, the reference publication on the subject, defines Zero Trust as a set of design principles centered on protecting individual resources rather than network segments.

The operating principle is "never trust, always verify." In practice, this means that trust ceases to be binary and permanent (a VPN authenticates you once and grants you access to everything) and becomes dynamic and contextual: evaluated at each access based on identity, device posture, location, resource sensitivity, and real-time risk signals. If the context changes — a device loses compliance, a login originates from an anomalous country — access is reassessed or revoked.

The conceptual pillars of NIST SP 800-207 underpin the model: every data resource and service is treated as a resource to be protected; access is granted per session and by least privilege; the access decision is made by a dynamic policy that considers the observable state of the requester; and the enterprise continuously monitors and measures the integrity and security posture of all assets. No asset is trusted by default.

Architecturally, this materializes in three logical components: the Policy Engine (which decides to grant or deny), the Policy Administrator (which enacts the decision by establishing or ending the session), and the Policy Enforcement Point (PEP, the point that intercepts traffic and applies the decision). Every access attempt passes through this control plane before touching the protected resource in the data plane. At Decripte, we implement Zero Trust architectures by designing exactly this decision flow for the client's real environment, without operational disruption.

The five pillars of Zero Trust (NIST SP 800-207 and the CISA maturity model)

CISA's Zero Trust Maturity Model (from the US Cybersecurity and Infrastructure Security Agency), in version 2.0, organizes implementation into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. These pillars are supported by three cross-cutting capabilities — Visibility and Analytics, Automation and Orchestration, and Governance — which must evolve together. Each pillar progresses through four maturity stages: Traditional, Initial, Advanced, and Optimal.

Identity is the central pillar and the natural starting point. It involves strong authentication (phishing-resistant MFA such as FIDO2/WebAuthn), risk-based authorization, centralized identity management (IAM), and least-privilege access assignment. At the Optimal stage, authentication is continuous and authorization adapts dynamically to session risk, rather than validating only at initial login.

Devices cover the complete asset inventory, posture verification (patching, disk encryption, active EDR, compliance), and access decisions conditioned on the endpoint's health state. An unmanaged or non-compliant device does not receive the same access as a verified corporate one. Networks address segmentation and microsegmentation, encryption of internal traffic (not just at the edge), and the removal of location-based trust — being on the internal network no longer confers privilege.

Applications and Workloads require that access to each application — including APIs, microservices, and cloud workloads — be authorized individually, with continuous integration of security into development (DevSecOps) and runtime protection. Data, the final pillar, is the objective of the entire architecture: classify, encrypt at rest and in transit, apply granular access control, and label information so that policy knows what it is protecting. Decripte assesses the client's maturity pillar by pillar against the CISA model, producing a stage-by-stage evolution roadmap rather than a single flip of the switch.

Identity is the new perimeter: IAM, strong MFA, least privilege and PAM/JIT

With remote work, SaaS, and the cloud, the network perimeter has ceased to exist as a defensive boundary — identity has become the real perimeter. Most modern breaches involve compromised credentials, which is why identity and access management (IAM) is the foundation of any Zero Trust architecture. Centralizing identity in a single provider (IdP) with SSO federation reduces the attack surface and gives a single point to apply policy.

MFA is mandatory, but not all MFA is equivalent. SMS-based factors and OTP codes are vulnerable to phishing and SIM swap. The Zero Trust standard requires phishing-resistant MFA — FIDO2/WebAuthn security keys or passkeys bound to the domain (origin-bound), which cannot be intercepted by a fake site. For fintechs and crypto platforms, where the impact of a compromised account is direct and financial, phishing-resistant MFA on privileged and customer accounts is not optional.

Least-privilege access means granting each identity only the permissions strictly necessary for its function, for only as long as needed. Combined with this, just-in-time (JIT) access eliminates standing privileges: instead of an administrator having root access all the time, they request the privilege when needed, with approval and a limited window, and the access expires automatically. This drastically reduces the exploitation window of a stolen credential.

PAM (Privileged Access Management) manages, vaults, and monitors the most powerful accounts — domain administrators, production root, cloud keys, wallet access, and payment systems. Good PAM practices include a credential vault with automatic rotation, session recording, access approval, and the elimination of static passwords in scripts and code. Decripte implements IAM, phishing-resistant MFA, and PAM with JIT as the first wave of the Zero Trust journey, because that is where risk is concentrated and the security return is most immediate.

Network microsegmentation: containing lateral movement

Microsegmentation divides the network into isolated, policy-governed zones, so that compromising one host does not give the attacker free access to the rest of the environment. In traditional perimeter architectures, once the intruder gets in (via phishing, for example), they move laterally with little resistance — this is how a minor incident becomes a full domain breach. Microsegmentation attacks exactly this vector: lateral movement.

Unlike classic segmentation by VLAN or edge firewall, microsegmentation applies granular controls at the workload, application, or even process level. The rules are based on identity and attributes (which service can talk to which service, on which port, under which context) and not just IP address. The result is a "deny by default" policy: no east-west communication (between internal workloads) is allowed unless explicitly authorized.

Practical implementation starts with observability: you must first map the real communication flows between systems before applying rules, on pain of breaking legitimate dependencies. Agent-based or service-mesh segmentation tools let you visualize dependencies, create policies in monitoring mode, validate, and only then move to enforcement. ZTNA (Zero Trust Network Access) complements this by replacing the VPN with per-application access, without exposing the entire network.

For cloud and hybrid environments — the typical case of the startups and e-commerce businesses Decripte serves — microsegmentation relies on security groups, Kubernetes NetworkPolicies, and workload identity. The principle is the same: each connection is explicitly authorized, internal traffic is encrypted, and network position never confers trust on its own.

How to implement Zero Trust step by step, without halting operations

Zero Trust is not deployed with a "big bang" — a flip of the switch that rewrites the entire network at once would break operations and generate resistance. The correct approach is incremental and iterative, evolving through protect surfaces prioritized by risk, with each wave validated before the next. The established methodology starts by defining what to protect, mapping how the data flows, designing the architecture, and only then applying and monitoring the policy.

The first move is to define the protect surface: identify the most critical data, assets, applications, and services (the DAAS model) — customer data, payment systems, wallets, intellectual property. It is much smaller and more stable than the attack surface, and concentrating effort on it delivers quick wins. Next, map the transaction flow around these assets: who accesses them, from where, through which systems, and how frequently.

With the flow mapped, design the Zero Trust architecture around that specific surface — where the policy enforcement points (PEPs) will sit, how identity will be verified, how traffic will be segmented. The policy is then created using the Kipling method (who, what, when, where, why, and how each access is allowed), starting in monitoring mode to validate without blocking, and only then moving to enforcement. Finally, continuously monitor and adjust, expanding to the next protect surface.

The key to not halting operations is controlled parallelism: new controls run alongside legacy ones, in observation mode, until they prove they do not break legitimate flows. MFA is activated for pilot groups before the whole company; microsegmentation runs in log-only before blocking; JIT access coexists with standing access until the migration is validated. Decripte runs this journey in waves, with acceptance criteria per stage, precisely so that security and availability advance together.

Common mistakes and myths: Zero Trust is not a product

The most widespread myth is that Zero Trust is a product you buy and install. It is not — it is a strategy and an architecture, sustained by principles, policy, and processes. Vendors sell components that enable Zero Trust (IdP, ZTNA, EDR, microsegmentation tools, PAM), but no single box delivers the architecture. Treating Zero Trust as a product purchase leads to investing in tools without redesigning policy and governance, and the result is apparent security without a real reduction in risk.

Another frequent mistake is neglecting the discovery phase. Applying microsegmentation or restrictive policies without first mapping identities, assets, and data flows breaks production systems and undermines the business's confidence in the project. Visibility precedes enforcement: you cannot protect or segment what you do not know. Device inventory, an identity map, and flow discovery are prerequisites, not details.

There is also the misconception of treating Zero Trust as a project with an end date. Because it is based on continuous verification and adaptation to risk, it is a permanent program, not a one-off deliverable. Likewise, focusing only on the network and ignoring identity, devices, applications, and data produces a partial and fragile implementation — the five pillars must evolve in a coordinated way, as the CISA model prescribes.

Finally, underestimating the human factor and governance dooms the project. Zero Trust imposes friction (more authentication, less standing access); without communication, pilots, and experience tuning, shadow IT emerges and controls get bypassed. Decripte treats Zero Trust as a continuous program, with governance, maturity metrics, and iteration — not as a license to be activated.

Passo a passo

1. Define the protect surface: inventory and prioritize by risk the critical data, assets, applications, and services (the DAAS model) — customer data, payment systems, wallets, intellectual property. Start with what hurts most to lose, not with the entire network.
2. Map identities, devices, and data flows: discover who accesses what, from which devices, and through which paths. Without visibility there is no safe enforcement — this discovery phase prevents breaking production systems.
3. Establish identity as the perimeter: centralize identity in an IdP with SSO, enforce phishing-resistant MFA (FIDO2/WebAuthn/passkeys), and apply least-privilege access to all accounts, prioritizing privileged ones.
4. Deploy PAM with just-in-time access: vault privileged credentials, enable automatic rotation and session recording, and eliminate standing privileges by replacing them with temporary, approved, expiring access.
5. Apply microsegmentation in monitoring mode: map the east-west flows, create identity-based communication policies between workloads in log-only, validate that nothing legitimate breaks, and only then move to deny-by-default enforcement.
6. Replace the VPN with ZTNA and encrypt internal traffic: grant per-application access instead of full-network access, verifying identity and device posture at each session, and remove location-based trust.
7. Monitor, measure maturity, and expand in waves: instrument continuous visibility and analytics, assess each pillar against the CISA maturity model, adjust the policy, and repeat the cycle for the next protect surface.

Perguntas frequentes