For two decades, the network defense strategy rested on a simple assumption: build a high enough wall and everything inside will be safe. VPN gave employees access to the corporate network, and a firewall guarded the boundary between the “trusted” interior and the “dangerous” internet. This model was convenient to administer and easy for boards of directors to understand. It had one fundamental problem, however — it assumed that an attacker would never find themselves on the “right” side of the wall.
Today we know that assumption is false. The Verizon Data Breach Investigations Report 2024 shows that more than 74% of data breaches involve a human element — phishing, errors, or abuse of privileges. When an attacker obtains stolen credentials or compromises an employee’s device, the traditional perimeter architecture has nothing left to offer: the intruder is inside and can move freely across the network.
The zero trust model responds to this threat with a radical shift in the foundational assumption: trust no one and nothing by default, regardless of their location in the network. Every access request — from an employee in the office, from an application in the cloud, from a business partner — is treated as a request from an unknown, potentially hostile source and must undergo full verification. This article shows how to translate that philosophy into concrete technical and organizational actions.
What is zero trust and why is the perimeter model no longer sufficient?
Zero trust is a security architecture based on the principle of “Never Trust, Always Verify.” The concept was formalized in 2010 by Forrester Research analyst John Kindervag, and it gained mainstream acceptance after NIST published document SP 800-207 “Zero Trust Architecture” in August 2020. Today it serves as the reference point for ENISA, the Cybersecurity and Infrastructure Security Agency (CISA) in the United States, and CERT Polska in the context of implementing the requirements of the NIS2 directive.
The perimeter model worked effectively in an era when IT infrastructure was physically concentrated in a data center, employees used company computers in the office, and applications were deployed on-premises. In that reality, the network boundary was clear and defensible. The modern IT environment looks entirely different: data resides across multiple clouds, employees work remotely from personal devices, SaaS applications replace on-premises systems, and business partners and external vendors need access to internal resources. The network perimeter has ceased to exist as a unified line of defense.
A Gartner study from 2024 indicates that 78% of organizations experienced at least one security incident that resulted directly from excessively broad access permissions granted to internal users or contractors. This phenomenon — referred to in security terminology as “lateral movement,” meaning an attacker’s movement through the internal environment — is only possible because the traditional model assumes trust for anyone who has passed through the network gate.
Zero trust eliminates that assumption through three fundamental principles: verify explicitly (every access request must be authenticated, authorized, and encrypted regardless of its source), apply the principle of least privilege (users and systems receive only those permissions that are absolutely necessary, for the time necessary to complete a task), and assume breach (design the architecture as if an attacker is already inside the network, focusing on limiting the scope of compromise and enabling rapid detection).
The traditional perimeter model asks: “Is the user on the network?” Zero trust asks: “Should this specific user, from this specific device, in this specific context, have access to this specific resource right now?” This change of question changes the entire security architecture.
An important consequence is a shift in thinking about location. In the zero trust model, accessing a resource from an office computer connected to the corporate Wi-Fi network is not inherently safer than accessing it from a coffee shop via the internet. Both requests undergo identical verification. This is critical in a hybrid work environment where “inside” and “outside” have ceased to be security categories.
📚 Read the complete guide: IAM / Zero Trust: Zarządzanie tożsamością i dostępem - od podstaw do Zero Trust
What are the pillars of zero trust architecture — identity, device, network, data, application?
Zero trust architecture is not a single product or a single technology. It is a model consisting of five mutually complementary pillars, each contributing a different aspect of verification and control. Implementing zero trust means progressively strengthening each of these pillars, not purchasing a “zero trust solution” all at once.
The identity pillar is the foundation of the entire architecture. In the zero trust model, identity replaces network location as the primary criterion of trust — which is why it is said that “identity is the new perimeter.” Strong authentication (MFA), identity management (IAM/IdP), and continuous verification of session state are the elements that build confidence in who the entity requesting access actually is. Identity covers not only employees but also machine identities: service accounts, applications, cloud workloads, and IoT devices.
The device pillar answers the question: what device is the request coming from, and does that device meet the security requirements? Device Trust means the system checks the state of a device before granting access — whether it has an up-to-date operating system, active endpoint protection, enabled disk encryption, and no traces of malware. A device that does not meet the health policy (device health) receives limited access or is directed to a quarantine network.
The network pillar encompasses microsegmentation, control of East-West traffic (between internal segments), and segment isolation. In a zero trust architecture, every application, workload, or group of resources is treated as a separate security zone. Traffic between zones is blocked by default and requires an explicit allow rule. Encryption of internal traffic (mTLS between services) becomes the standard, not the exception.
The application pillar involves implementing access control at the application level itself, independently of the network level. A user authenticated in the IAM system does not automatically gain access to all applications — each has its own authorization policies, integrated with a central policy engine. Techniques such as proxy-based application access (used in ZTNA) allow applications to be completely hidden from unauthenticated users — the application is neither visible nor addressable to entities without an active, verified session.
The data pillar closes the architecture through data classification, granular access control, and monitoring of data flows. Data Loss Prevention (DLP), Information Rights Management (IRM), and continuous auditing of who accessed what data and when — these are the elements that make it possible to minimize the risk of exfiltration even in the event of a user account compromise. In the zero trust model, data is protected regardless of where it resides: on an on-premises server, in the cloud, in a SaaS application, or on an endpoint device.
The five pillars of zero trust — identity, device, network, application, data — must operate as an integrated system. Strengthening one pillar while neglecting the others gives an attacker an alternative entry vector. Zero trust transformation is a multidimensional process, not a series of independent IT projects.
The NIST SP 800-207 architecture distinguishes two key logical components that connect these pillars: the Policy Engine (PE) — the component that makes access decisions based on all available contextual signals — and the Policy Enforcement Point (PEP) — the element that enforces that decision at the point of access to the resource. Every access request passes through the PEP, which consults the PE before granting or denying access. Understanding this logic is essential when designing integrations of tools within a zero trust stack.
How to begin a zero trust implementation — where to start the transformation?
The most common mistake when implementing zero trust is attempting a “big bang” approach — replacing the entire security infrastructure all at once. In a large organization, this is a path to operational chaos, frustration for IT teams and users, and an almost guaranteed failure of the initiative. The right approach is iterative and based on risk prioritization.
The first step is inventory and asset classification. You cannot protect what you do not know about. A complete inventory covers: all data assets (where they are, who has access, how they are categorized in terms of sensitivity), all applications and systems (critical, important, administrative), all users and identities (employees, contractors, service accounts, machine identities), and all devices (company-managed, personal BYOD, IoT). Without this map, it is impossible to design meaningful access policies.
The next step is mapping data flows and identifying “protect surfaces” — the most important assets that require protection first. The concept of a protect surface is a fundamental difference from traditional thinking about “attack surface.” Instead of trying to reduce the entire attack surface (which is an endless task), the focus is on defining key assets and building tight controls around them. Typical protect surfaces include: ERP and financial systems, customer databases, OT/SCADA systems, and critical business applications.
The third step is documenting transactional flows around protect surfaces: who accesses these resources and how, what protocols are used, what dependencies exist between systems. This knowledge is essential for designing microsegmentation policies and access controls without disrupting business operational continuity.
Based on this analysis, an implementation roadmap can be created, prioritizing actions according to a combination of risk and feasibility. “Low-hanging fruit” topics — such as deploying MFA on the highest-privilege accounts — deliver an immediate, measurable improvement in security at a relatively low implementation effort. Projects of high complexity (full network microsegmentation, replacement of VPN with ZTNA) are scheduled for subsequent phases.
The human dimension must not be overlooked either. Zero trust changes the way people work: users will encounter new verification steps, new access restrictions, and new procedures. Change management and communication with employees are an integral part of every successful zero trust program. Organizations that implement zero trust without informing and engaging users generate resistance, workarounds, and ultimately a weakening of security.
The first three months of a zero trust program should be devoted primarily to understanding the environment, not changing it. Asset inventory, flow mapping, and protect surface identification are analytical work that conditions the success of all subsequent phases. Organizations that skip these steps build zero trust on an uncertain foundation.
How to implement strong authentication and identity verification?
Authentication is the first and most important layer of the zero trust model. Without reliable identity verification, the rest of the architecture loses its meaning — it does not matter how rigorous the access policies are if anyone can impersonate an authorized user through a stolen or guessed password.
Multi-factor authentication (MFA) is the absolute minimum. The Microsoft 2024 Security Report indicates that MFA blocks more than 99.9% of password-based account takeover attacks. Despite this, many organizations have still not deployed MFA for all accounts or apply it only to selected systems. Prioritization is straightforward: first, MFA on privileged accounts (administrators, DevOps, CISO and C-suite), then on all accounts with access to critical systems, and ultimately — on all accounts without exception.
Not all MFA is equally secure. SMS codes are vulnerable to SIM swapping and SS7 attacks — they should be treated as a minimum safeguard, not the target standard. Authenticator applications generating TOTP (Time-Based One-Time Password) codes (e.g., Microsoft Authenticator, Google Authenticator) are significantly more secure. FIDO2/WebAuthn hardware keys (e.g., YubiKey) perform even better, being resistant to phishing and man-in-the-middle attacks — particularly for administrative accounts.
Single Sign-On (SSO) from a central Identity Provider (IdP) is essential for scalability. An IdP (e.g., Microsoft Entra ID, Okta, Google Workspace Identity) becomes the central authentication point for all applications — both cloud-based and on-premises. The benefits are twofold: users log in once, and the organization’s security gains a single point of control where consistent policies can be applied, anomalies analyzed, and MFA enforced.
Adaptive Authentication is the next level of identity verification, characteristic of the zero trust approach. The system analyzes the context of a login and dynamically adjusts the requirements: a login from a trusted device, from a regular location, at a typical time may require only a password and MFA. A login from a new device, from an unfamiliar geographic location, or after a gap in activity — requires additional verification or is temporarily blocked pending investigation.
For machine identities (service accounts, API tokens, application certificates), the same rules apply as for human identities — each must be registered, managed, and regularly rotated. Many organizations have dozens, if not hundreds, of service accounts with unknown permissions and passwords that have not been changed in years. Inventorying and managing the lifecycle of machine identities is one of the most important and most frequently neglected aspects of a zero trust implementation.
No zero trust architecture can substitute for strong authentication. MFA is not an option — it is the foundation. Organizations that begin zero trust implementation with network microsegmentation or advanced ZTNA tools before ensuring universal MFA are putting the cart before the horse.
How to implement the principle of least privilege in practice?
The Principle of Least Privilege (PoLP) states that every user, system, or process should have access only to those resources that are absolutely necessary to perform their current task — and no more. In theory it is simple and obvious. In practice, implementing it in a large organization is one of the greatest operational challenges of the entire zero trust program.
The main problem is the phenomenon of “privilege creep” — the gradual accumulation of permissions. Over the years an employee gets promoted, changes roles, participates in various projects — each time they receive new permissions, but old ones are rarely revoked. After several years, a typical employee’s account has access to dozens of systems, most of which they do not use. From a security perspective, each of these unnecessary permissions is a potential attack vector.
Role-Based Access Control (RBAC) is the starting point for organizing permissions. Permissions are not assigned directly to users but to business roles, and roles are assigned to users. A well-designed role model reflects the actual structure of responsibilities: a Financial Analyst has access to accounting systems but not to HR systems and vice versa. It is essential that role design take place in close collaboration with the business — not from the perspective of “what is technically possible to configure,” but “what permissions are genuinely needed to perform this job.”
For privileged accounts, the appropriate solution is Privileged Access Management (PAM). PAM systems (e.g., CyberArk, BeyondTrust, Delinea) eliminate standing administrative passwords by replacing them with one-time credentials valid only for the duration of a specific session. The administrator does not know the password to a server — they request access, the PAM system verifies their authorization, generates temporary credentials, and makes them available for the duration of the task. After the session ends, credentials are automatically rotated. Privileged sessions are recorded and retained for audit purposes.
Just-In-Time (JIT) Access extends the PAM concept to a broader category of permissions. Instead of standing permissions to a system, a user receives them on demand, for a defined period, after approval by a supervisor or a workflow system. Once the defined time period elapses, permissions are automatically revoked. JIT access is particularly valuable for access to production environments, databases containing personal data (GDPR), and critical systems where standing access is operationally unjustified.
Regular access reviews (Access Reviews / Access Recertification) are essential for maintaining the PoLP principle over time. Managers and system owners regularly (quarterly or semi-annually) review and confirm the permissions assigned to their employees and systems. IGA (Identity Governance and Administration) tools automate this process, generating review campaigns, collecting decisions, and documenting results for the purposes of compliance audits (NIS2, GDPR, ISO 27001).
Privilege creep is one of the most difficult phenomena to eliminate in IT security. It requires a change in organizational culture: permissions should be granted intentionally and temporarily, not “just in case.” The principle of deny-by-default must become the norm, not the exception.
How does microsegmentation support the zero trust model?
Microsegmentation is a technique for dividing a network or computing environment into very small, isolated segments, between which traffic is blocked by default and requires explicit authorization. It is the operational realization of the “assume breach” principle from the zero trust model: even if an attacker compromises one element of the environment, microsegmentation limits their ability to move laterally and access other systems.
In a traditional network architecture, firewalls protect the external boundary (North-South traffic), but internal traffic between servers and applications (East-West traffic) is largely uncontrolled. An attacker who establishes a foothold in the internal network can freely scan, explore, and attack other systems. Microsegmentation transforms this flat network into an environment with multiple internal boundaries, each with its own access control.
There are three main approaches to microsegmentation. Network-based segmentation relies on VLANs, virtual firewalls, and Software-Defined Networking (SDN). It allows segmenting physical and virtual systems but requires advanced network rule management and can be difficult to scale in dynamic cloud environments. Host-based segmentation uses agents installed on servers and workstations that enforce policies directly at the operating system level, regardless of network topology. It is far more flexible and better suited for hybrid and multi-cloud environments. Application-level segmentation — most commonly implemented through a Service Mesh (e.g., Istio) in Kubernetes environments — controls traffic between microservices using mutual TLS (mTLS) and policy engines.
The practical implementation of microsegmentation should begin with mapping application flows. Traffic analysis tools (flow analytics) observe actual traffic in the environment over several weeks, identifying which systems communicate with each other and what protocols and ports are used. Based on this map, “allow” rules are designed for justified flows, and everything else is blocked. This process — building policies based on observed flows rather than intuition — is essential for avoiding accidentally blocking critical application dependencies.
Vendors offering microsegmentation tools include Illumio, Guardicore (Akamai), and Cisco Tetration. Most major cloud platforms (AWS Security Groups, Azure Network Security Groups, GCP VPC Firewall) offer native microsegmentation mechanisms for cloud resources.
Microsegmentation is a technique that dramatically increases the “cost” for an attacker. Instead of moving freely around the network after a single compromise, they must separately overcome the defenses of each segment. This transforms the defense model: even if the external perimeter is breached, successive layers of segmentation contain the scope of the incident and provide time for detection and response.
How to monitor and continuously validate trust?
Zero trust does not end with user authentication. A session that began with a correct login may be taken over by an attacker during its lifetime — through theft of a session token, a keylogger, or an exploit on the device. The zero trust model therefore requires continuous validation of trust throughout the entire duration of a session, not only at its initial moment.
Continuous session monitoring is based on real-time analysis of contextual signals. The system tracks: geographic location (has the user suddenly “jumped” between countries?), device (is the device certificate still valid, has the device’s health state changed?), behavioral patterns (is the user acting in accordance with their typical activity profile?), resources accessed (are they attempting to access resources outside their typical scope?). Anomalies in any of these signals trigger escalation: requiring additional MFA verification, restricting session permissions, or immediately terminating the session.
User and Entity Behavior Analytics (UEBA) is a technology that learns the normal behavior of each user and system, then detects deviations from that norm. UEBA systems (often integrated with SIEM, e.g., IBM QRadar SIEM with the UBA module, Microsoft Sentinel, Splunk) analyze thousands of parameters: what time does the user typically log in, which applications do they access during the day, how much data do they typically download, from what locations do they connect. The detection of a statistically significant anomaly (e.g., mass data download at 3 a.m. by an account that is normally active 9–5) generates an alert and can automatically trigger a response.
Security Information and Event Management (SIEM) is the central hub for correlating security events from across the zero trust environment. Logs from the IdP (authentications), from ZTNA/proxy (application access requests), from endpoint protection (device events), from microsegmentation (rejected connections), from DLP (data exfiltration attempts) — all these data streams must be aggregated and correlated so the system can build a complete picture of an incident. An alert from a single source may be a false alarm; the correlation of four different signals from four different layers is an almost certain indicator of a real threat.
Security Orchestration, Automation and Response (SOAR) closes the loop by automating the response to detected anomalies. Instead of waiting for a SOC analyst to manually process an alert and make a decision, the SOAR platform executes predefined playbooks: isolates the device from the network, forces re-authentication of the user, escalates a ticket to an analyst, creates an environment snapshot for forensic analysis. Automated response reduces the time from detection to isolation from minutes or hours to seconds.
A key indicator of the effectiveness of continuous monitoring is MTTD (Mean Time To Detect) — the average time from the moment of compromise to its detection. The IBM Cost of a Data Breach 2024 report indicates that organizations with advanced SIEM and automation detect breaches an average of 108 days faster than organizations without these tools. In the zero trust context, where we assume that a breach is inevitable, MTTD is one of the most important measurable outcomes of a security program.
Continuous monitoring is what distinguishes zero trust from a static security configuration. Access policies must respond to current contextual signals: the same user, the same application, the same time of day, but a different device or different location — the access decision should be different. Trust in the zero trust model is dynamic, not one-time.
What tools support zero trust implementation — ZTNA, SASE, SDP?
The zero trust tools market is large and continually growing, which can be disorienting. It is worthwhile to understand the key technology categories, their interrelationships, and typical use cases in order to consciously select components for your own security stack.
ZTNA (Zero Trust Network Access) is the technology that replaces traditional VPN in the zero trust model. VPN provides access to the entire network — every connected user can see all resources on the network. ZTNA provides access to specific applications, not to the network. The user connects to a ZTNA broker/proxy, which verifies their identity, device health, and access policies, then establishes an encrypted tunnel only to those applications the user is authorized to access. All other applications are invisible and unreachable to that user. ZTNA can operate in a “cloud-delivered” model (access to cloud and on-premises applications through a cloud proxy) or an “on-premises” model (for environments with restrictions on transmitting data through external clouds). Leading ZTNA vendors include Zscaler Private Access (ZPA), Cloudflare Access Prisma Access, and Cisco Duo.
SASE (Secure Access Service Edge) is a convergent architecture that combines networking functions (SD-WAN) and security functions (ZTNA, SWG — Secure Web Gateway, CASB — Cloud Access Security Broker, FWaaS — Firewall as a Service) in a single platform. Instead of several point products integrated through configuration, SASE delivers integrated capabilities from a single cloud-managed platform. This architecture is particularly attractive for organizations with multiple branches that make heavy use of cloud and SaaS services, where managing many separate security products generates significant operational complexity. Leading SASE vendors: Zscaler, Cloudflare One, Cisco.
SDP (Software Defined Perimeter) is an approach in which the network infrastructure is “dark” to all entities without prior authorization. Resources protected by SDP are not visible on the network — they do not respond to pings and have no open ports accessible to unauthorized entities. Access is established through special client software (an SDP client) that first authorizes identity and device, and only after a positive verification establishes an encrypted communication channel. SDP is particularly effective at eliminating network-level attacks such as port scanning and brute-force attacks against public services.
IAM/IdP (Identity and Access Management / Identity Provider) is the essential foundation: Microsoft Entra ID (Azure AD), Okta, Ping Identity, Google Cloud Identity. It serves as the central identity provider, enforces MFA and conditional access policies.
PAM (Privileged Access Management): CyberArk, BeyondTrust, Delinea — privileged access management, password vaulting, session recording.
SIEM + UEBA: IBM QRadar SIEM, Microsoft Sentinel, Splunk Enterprise Security — the central hub for event correlation and behavioral analytics.
Endpoint Detection & Response (EDR/XDR): CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne — visibility and control at the endpoint device level, a key element of the “device” pillar in zero trust.
Tool selection should be driven by strategy, not precede it. Before purchasing any zero trust product, it is worth answering these questions: which pillars of the architecture need strengthening first? What integrations will be needed with the existing stack? What is the team’s operational capacity to manage a new tool? The best tool is not the most expensive one — it is the one that addresses the identified gaps and is operationally manageable by your team.
When selecting vendors, it is worth paying attention to vendors holding independent certifications and validations: Gartner Magic Quadrant positioning, FIPS 140-2 certifications for cryptographic modules, and compliance with NIST SP 800-207.
What does a zero trust implementation roadmap look like?
The following table presents a strategic zero trust implementation roadmap divided into six phases corresponding to successive priorities. The duration of each phase is indicative and depends on the size of the organization, the maturity of the existing infrastructure, and the available resources. In larger organizations, phases often overlap — work on the third phase begins before the second phase is fully completed.
| Phase | Name | Key Actions | Technologies | Indicative Duration | Success KPI |
|---|---|---|---|---|---|
| 1 | Knowledge Foundations | Asset, data, and identity inventory; flow mapping; protect surface identification; current-state maturity assessment | Asset discovery, network flow analysis, CMDB | 6–8 weeks | 100% of critical assets inventoried; flow map for top-10 applications |
| 2 | Identity and Authentication | IdP deployment/consolidation; universal MFA for privileged accounts; SSO for critical applications; machine identity inventory | Microsoft Entra ID / Okta, YubiKey / FIDO2, SSO federation | 2–3 months | MFA on 100% of privileged accounts; SSO for at least 80% of critical applications |
| 3 | Privileged Access Management | PAM deployment; elimination of standing administrative passwords; privileged session recording; JIT access for production environments | CyberArk / BeyondTrust / Delinea | 2–3 months | Zero standing administrative passwords; 100% of privileged sessions recorded |
| 4 | Microsegmentation | East-West flow mapping; segmentation of critical applications; deny-by-default policy deployment; gradual scope expansion | Illumio / Guardicore / NGFW | 3–6 months | Isolation of top-5 protect surfaces; reduction of allowed East-West traffic by at least 60% |
| 5 | Application Access (ZTNA) | Replacing VPN with ZTNA for remote workers; deploying application proxy for internal applications; extending to partner/contractor access | Zscaler ZPA / Cloudflare Access / Cisco Duo | 3–4 months | 100% of remote access through ZTNA; elimination of VPN split-tunnel |
| 6 | Continuous Monitoring and Automation | Log centralization in SIEM; UEBA deployment; SOAR playbook development; regular access reviews (Access Recertification) | SIEM, UEBA, SOAR, IGA | 3–4 months + ongoing | MTTD < 24h; 80% of high-confidence alerts handled automatically |
A few important notes on the roadmap. First, Phase 1 (inventory) is frequently underestimated and underfunded — yet it is the most important. Organizations that skip this phase implement zero trust “in the dark” and inevitably encounter costly surprises. Second, Phases 2 and 3 (identity and PAM) should be treated as priorities because they deliver an immediate and measurable improvement in security. Third, Phase 6 (monitoring) is not the “final phase” — it is a permanent operational state that begins to be built from the start of the program, and after the completion of Phase 6 it enters a mode of continuous improvement.
A key strategic success factor is treating each phase as an opportunity to demonstrate business value. Zero trust should not be perceived as an “IT security project” — it should be positioned as a “business risk management program” enabling secure hybrid work, compliance with NIS2 and GDPR, faster deployment of new applications (since they do not require integration with a traditional perimeter network), and lower operational costs compared to an extensive VPN infrastructure.
How does nFlo help organizations implement zero trust architecture?
nFlo works with organizations at every stage of security maturity — from companies that are just beginning to think about zero trust, to technically advanced organizations that need support implementing specific architectural components or validating their existing efforts. Over the course of more than 500 projects completed with 200+ clients, we have developed a methodology that combines deep technical knowledge with an understanding of the operational realities of Polish organizations — including requirements arising from NIS2, GDPR, and sector-specific security regulations.
Every engagement begins with a maturity assessment (Zero Trust Maturity Assessment), which verifies the current state of the five zero trust architecture pillars according to the CISA Zero Trust Maturity Model. The result is a report containing a gap map, prioritization of actions, and technology recommendations tailored to the client’s environment — not a generic checklist, but a concrete action plan.
For organizations embarking on zero trust transformation, we offer an implementation program encompassing: target architecture design, support in selecting and deploying tools (IAM/IdP, MFA, PAM, ZTNA, microsegmentation, SIEM), development of access policies and operational procedures, and training for IT and SOC teams. We act as a technology partner throughout the entire transformation cycle, ensuring business operational continuity during infrastructure changes.
For organizations that already have existing zero trust elements in place, we offer configuration audits (verifying policy compliance with the least privilege principle, reviewing microsegmentation rules, assessing MFA status and machine identity management) and penetration tests aimed at validating the effectiveness of the implemented architecture. 98% of clients who have used our zero trust audits discovered at least one significant gap they were unaware of before the audit.
An incident response time of under 15 minutes is the operational standard we maintain for clients using our SOC as a Service — which, combined with the implemented zero trust controls, enables a time from detection to isolation (MTTR) that is impossible to achieve with self-managed security. The target risk reduction following full implementation of the zero trust architecture, as confirmed across our projects, is 90%.
If your organization is facing the question of “where to start with zero trust?” or “is our current implementation effective?”, we invite you to speak with our experts. We do not offer off-the-shelf solutions — every project begins with understanding the context of your business, your threats, and your operational capabilities.
FAQ — Frequently Asked Questions
Is zero trust a product that can be purchased and deployed?
No. Zero trust is a security strategy and architecture, not a product. No single vendor offers a complete zero trust solution “in a box.” Implementing zero trust requires integrating multiple technologies (IAM, MFA, PAM, ZTNA, microsegmentation, SIEM), changing operational processes, and transforming organizational culture. Many vendors use the term “zero trust” as a marketing label for their products — it is worth evaluating these according to which of the five architectural pillars (identity, device, network, application, data) they actually address and how they integrate with other components.
How long does a zero trust implementation take and what does it cost?
The timeline of zero trust transformation in a typical mid-sized organization (500–2,000 employees) ranges from 12 to 24 months for the basic phases (identity, PAM, ZTNA) to 36 months or more for a full architecture encompassing microsegmentation and advanced monitoring. It is a multi-year investment, not a one-time project. Costs are difficult to generalize without knowledge of the specific environment, but typical projects include: tool licenses (often the largest cost), implementation services, training, and internal costs (time of IT and SOC teams). The good news: many organizations already have some of the required tools (e.g., Microsoft Entra ID P2 or Okta included in Microsoft 365 E3/E5 licenses) — the right starting point is an audit of existing licenses before purchasing new ones.
Does zero trust conflict with employee productivity?
Poorly implemented zero trust can significantly reduce productivity — constant verifications, access blocks, and the absence of SSO forcing repeated logins. Well-implemented zero trust is nearly invisible to the user: SSO ensures smooth login to all applications, MFA at first login on a new device is a one-time effort, and adaptive authentication reduces the number of MFA challenges for “normal” access requests. The key is balancing security with usability — and close business engagement in designing access policies.
How does zero trust help with NIS2 and GDPR compliance?
The NIS2 directive (being implemented in Poland as an amendment to the National Cybersecurity System Act) explicitly requires the use of a risk management-based approach, network segmentation, privileged access control, and continuous monitoring — these are exactly the elements of zero trust architecture. Article 21 of NIS2 lists multi-factor authentication, segmentation, and secure communication as mandatory security measures. GDPR requires the implementation of appropriate technical measures protecting personal data — the principle of least privilege and microsegmentation directly limit the risk of unauthorized access to personal data. Zero trust is therefore not only a security best practice but also an effective tool for building compliance with applicable regulations.
Which zero trust pillar is the best place to start?
For most organizations, the best starting point is the identity pillar, and specifically: universal MFA for privileged accounts, consolidating identity management through a central IdP, and inventorying and managing machine identities (service accounts, API tokens). The rationale is straightforward: this is the fastest layer to deploy, it delivers an immediate and measurable improvement in security (blocking more than 99% of stolen-credential-based attacks), and it builds the foundation for all subsequent architectural layers. Before deploying expensive microsegmentation or ZTNA tools, it is worth ensuring that the foundations of identity management are solid.
Sources
- NIST (2020). Zero Trust Architecture. NIST Special Publication 800-207. National Institute of Standards and Technology. https://csrc.nist.gov/publications/detail/sp/800-207/final
- CISA (2023). Zero Trust Maturity Model Version 2.0. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model
- ENISA (2023). ENISA Threat Landscape 2023. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023
- ENISA (2023). Good Practices for Supply Chain Cybersecurity. European Union Agency for Cybersecurity. https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity
- Directive of the European Parliament and of the Council (EU) 2022/2555 of 14 December 2022 (NIS2). Official Journal of the European Union, L 333.
- Verizon (2024). Data Breach Investigations Report 2024. Verizon Communications Inc. https://www.verizon.com/business/resources/reports/dbir/
- IBM Security (2024). Cost of a Data Breach Report 2024. IBM Corporation. https://www.ibm.com/security/data-breach
- Gartner (2024). Magic Quadrant for Zero Trust Network Access. Gartner Inc.
- Microsoft (2024). Microsoft Digital Defense Report 2024. Microsoft Corporation. https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2024
- Kindervag, J. (2010). Build Security Into Your Network’s DNA: The Zero Trust Network Architecture. Forrester Research.
Related Concepts
Explore key terms related to this article in our cybersecurity glossary:
- Zero Trust — Zero Trust is an IT security model that assumes no person, device, or system is trusted by default.
- ZTNA — Zero Trust Network Access is a technology that replaces VPN, providing application access based on identity verification.
- Microsegmentation — Microsegmentation is a technique for dividing a network into isolated segments in order to restrict lateral movement.
- Least Privilege — The principle of least privilege restricts the access of users and systems to the minimum necessary to perform a task.
- PAM — Privileged Access Management is the management of access to privileged accounts using password vaults and session recording.
Learn More
Explore related articles in our knowledge base:
- What is ZTNA — Zero Trust Network Access?
- Zero Trust in organizational architecture — implementation step by step
- Identity and Access Management (IAM): who, what, where, when and why
- Zero Trust in OT networks: does “never trust” work in a PLC environment?
- Zero Trust in identity management — IAM as a defensive strategy
Check Our Services
Need cybersecurity support? See:
- Security Audits — comprehensive security posture assessment
- Penetration Testing — identifying vulnerabilities in your infrastructure
- SOC as a Service — around-the-clock security monitoring
Need expert support? nFlo team can help secure your organization:
