Zero Trust for digital-first companies

what Zero Trust actually is

The term was introduced by analyst John Kindervag at Forrester Research in 2010. The core observation was simple: perimeter-based security models assume that everything inside the network boundary is trusted, and that assumption is wrong. Internal accounts get compromised. Contractors bring unmanaged devices. Cloud services dissolve the perimeter entirely. Zero Trust replaces that assumption with a different one: no user, device, or connection is trusted by default, regardless of where it originates. Every access request is evaluated on the basis of who is asking, what they are asking for, from what device and context, and whether they should have it.

The National Institute of Standards and Technology (NIST) formalized this in SP 800-207, published in 2020. That document defines Zero Trust Architecture as a set of guiding principles for workflow, system design, and operations, not a single product or technology. That distinction matters when vendors say their platform "delivers Zero Trust." No single platform does. The model requires applying principles across multiple control areas.

the three principles

Every credible Zero Trust framework traces back to three principles. Verify explicitly: every access request is authenticated and authorized based on all available data points, with user identity, device health, location, and the sensitivity of the resource all feeding into the access decision, because a valid username and password alone is not sufficient verification. Use least privilege: users and systems receive the minimum access required to perform their current function, scoped by role, time, and context, with broad persistent permissions replaced by narrower grants that can be reviewed, adjusted, and revoked. Assume breach: design and operate as though an attacker is already present, segment access so a compromised account reaches only what it was permitted to reach, and log and monitor everything so abnormal access is detectable. These principles are interconnected: least privilege is only effective if access is verified continuously, and assuming breach only reduces damage if the environment is actually segmented. They are a system, not a checklist.

why identity is the foundation

In a cloud-first, distributed environment, network location has become a poor proxy for trust. A user on the corporate network can be a threat. A user on a home broadband connection can be legitimate. What remains constant, and what Zero Trust depends on, is identity. Identity is the control plane: the access decision starts with who this person is, whether their identity has been verified, whether their current device and context match what is expected, and whether their role justifies this access request.

This is why identity gaps undermine every other Zero Trust control. An account with no MFA can be reached with credentials alone, and the use of stolen credentials was involved in 36% of breaches (Verizon DBIR). An account that no longer belongs to an active employee but was never deprovisioned provides an attacker with a valid identity to operate from, and 83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). A user with far more access than their role requires gives a successful attacker a much larger blast radius. Before device posture checks, network segmentation, or continuous monitoring produce real value, the identity layer must be sound. The visibility question comes first: who has access to what, and is that still correct?

the practical building blocks

Zero Trust for a mid-market company is built from components that are already familiar. The work is in applying them deliberately and consistently.

Strong identity and MFA everywhere. One central identity provider that all users authenticate through, single sign-on so that closing a central account closes access everywhere that IdP governs, and MFA enforced on every account with no exceptions for admin accounts or legacy configurations. MFA blocks more than 99.2% of account-compromise attacks (Microsoft), and the figure applies to accounts with MFA enforced, so every account without it sits outside that protection. Admin accounts without MFA are the highest-privilege credentials in the environment protected by a password alone. For SaaS applications that authenticate directly rather than through the IdP, the IdP's MFA provides no protection, so those applications need their own MFA or need to be brought under SSO.

Least privilege and access reviews. User permissions scoped to current role and current need, with a review cycle, running quarterly for privileged accounts and half-yearly for standard access, where resource owners confirm who should still have what. Access accumulates by default: promotions add permissions, role changes add the new role's permissions without removing the old, and contractors whose projects ended still appear in the tools. Without a structured review cycle, permissions only grow.

Device posture. An access decision is stronger when it includes the health of the device making the request: whether it is managed, whether the OS is current, whether it is registered in the directory. Device posture checks are available through most modern IdPs and endpoint management platforms; at minimum this means distinguishing managed from unmanaged devices and applying stricter access policies to unmanaged ones.

Network segmentation. Flat internal networks, where any authenticated user can reach any system, expand the blast radius of a compromised account. Segmentation means a compromised account reaches only the systems it was meant to reach. For cloud environments this translates to well-scoped IAM policies, security groups, and resource-level permissions; the principle is the same, limit lateral movement by limiting what any single account can access.

Continuous verification and logging. Access granted at login should not be assumed to remain valid indefinitely. Session length, re-authentication requirements, and anomaly detection all contribute to continuous verification, and a session that behaves unexpectedly can trigger a step-up authentication or alert. Logging is the prerequisite for any of this: admin actions, authentication events, access to sensitive resources, and configuration changes should produce audit logs, because without logs anomaly detection has nothing to work with and incident response has no record to examine.

Privileged access management. Admin rights are the highest-value credential in any environment. The baseline practice is separation: a standard account for daily work and a separate admin account used only when elevated access is required, which keeps admin credentials out of the everyday phishing, browser, and clipboard exposure that daily-use accounts face. For environments with many privileged accounts, dedicated PAM tooling adds session recording, credential vaulting, and just-in-time access.

a phased starting path

Zero Trust does not require replacing infrastructure. The companies that stall on it are usually waiting for a budget cycle to fund a complete replacement; the companies that make progress start with what they have. Phase 1 is visibility: produce a complete inventory of accounts across the identity environment, including human, service, admin, and contractor accounts and OAuth grants, map which applications are under IdP or SSO governance and which authenticate independently, and check MFA coverage for every account starting with admin-level ones, treating the inventory as a baseline rather than a one-time exercise. Phase 2 is the identity foundation: enforce MFA on every admin account then every user account, bring unmanaged SaaS applications under SSO where possible, deprovision accounts belonging to former employees and contractors, and establish a basic joiner-mover-leaver process tied to HR events; this is the highest return-on-effort investment in the progression and closes the most commonly exploited gaps without new infrastructure. Phase 3 is least privilege and reviews: scope permissions to current role, run the first access review cycle, separate admin accounts from daily-use accounts, and establish a sustainable review cadence. Phase 4 is device posture and segmentation: introduce device compliance policies, distinguish managed from unmanaged devices in access policy, and segment the internal network and cloud IAM policies. Phase 5 is continuous verification and maturity: add anomaly detection and adaptive re-authentication, expand logging, introduce just-in-time access for privileged operations, and run access reviews as an embedded process. Most mid-market organizations can reach the end of Phase 3 without deploying any new security tooling, because the work is process and configuration, not procurement.

how it maps to standards

NIST SP 800-207 is the authoritative reference for Zero Trust Architecture, defining the principles, logical components, and deployment models. ISO 27001 Annex A controls covering access management (5.15, 5.18), authentication (8.2, 8.5), privileged access (5.16), and network segmentation (8.22) map directly to Zero Trust building blocks, so organizations building the model from the ground up satisfy many ISO 27001 controls in the process. NIS2 Article 21 requires access control, multi-factor authentication, and network segmentation, which are Zero Trust fundamentals. DORA's ICT security requirements (Article 9) include access control, privileged access management, and continuous monitoring, which a Zero Trust program addressing identity, least privilege, and logging covers. GDPR's data minimization and access limitation requirements are well-served by least privilege. Compliance is not the reason to build a Zero Trust program; the reason is that most breaches follow patterns the model is designed to interrupt, and compliance alignment is a byproduct of doing the work correctly.

common mistakes and vendor traps

Several large vendors sell platforms described as delivering Zero Trust, and buying one as a first step is a category error: some are genuinely useful components, but none deliver the model on their own, which requires identity, device, network, and monitoring layers working together, so vendor claims should be evaluated against NIST SP 800-207 and bought into the gaps in your existing architecture. Starting with network segmentation before identity is sound produces limited value, because an attacker with a valid, over-privileged credential can operate inside a well-segmented network; identity is the prerequisite. Treating Zero Trust as a project with an end date misreads it, because it is an operating model and the environment it governs changes continuously, so controls that are set up and not maintained degrade. Skipping the visibility phase produces policies that miss the actual gaps, the common version being an organization that enforces MFA through its IdP and has invested in endpoint management yet still has a dozen former employees with active accounts in SaaS applications that never connected to the IdP. And MFA gaps on legacy configurations remain years after MFA was "deployed", in the accounts that predated the policy, the admin configurations excluded for convenience, and the VPN that was never updated.