"Zero trust" has become one of the security industry's favorite labels: firewalls, VPNs, identity platforms and endpoint tools can all be packaged as a "zero trust solution". At the same time, the Taiwan Stock Exchange (TWSE) guideline for listed companies, revised in November 2026, says companies should "evaluate adopting a zero trust architecture, such as multi-factor authentication, for core information systems"[1]. That leaves many managers asking the same question: what exactly is zero trust, and does buying a particular product mean you have it?

The answer is in the definition from the US National Institute of Standards and Technology (NIST): zero trust is not a single architecture but a set of guiding principles, and it cannot be achieved by a wholesale replacement of technology[2]. This article is for IT staff and managers who need to assess vendor proposals or respond to the TWSE guideline. It explains NIST's definition, seven tenets and core components, introduces CISA's maturity model and NIST's example implementations, sets out what Taiwan's government and TWSE expect, and ends with a practical order of work for ordinary companies and the common pitfalls.

The definition: NIST SP 800-207

NIST published SP 800-207, Zero Trust Architecture, in August 2020[2]. Its abstract states the core idea up front: zero trust grants no implicit trust to assets or user accounts based solely on their physical or network location (for example, being on the corporate LAN rather than the internet) or on asset ownership; authentication and authorization of both the user and the device are separate steps completed before a session to an enterprise resource is established[2]. What is protected is resources (assets, services, workflows, accounts), not network segments[2].

NIST's formal definition is that zero trust is a collection of concepts and ideas designed to make accurate, least-privilege, per-request access decisions in the face of a network viewed as compromised, while a zero trust architecture (ZTA) is an enterprise's cybersecurity plan that uses those concepts and covers component relationships, workflow planning and access policies[2]. NIST is explicit that zero trust is not a single architecture but a set of guiding principles for workflow, system design and operations; moving to a ZTA is a journey of evaluating risk that cannot be accomplished with a wholesale replacement of technology, many organizations already have some of the elements, and most will run in a hybrid zero trust and perimeter-based mode for a long time[2].

The seven tenets

NIST lists seven basic tenets a zero trust architecture should follow[2]:

  1. All data sources and computing services are considered resources: including SaaS and small-footprint devices; an enterprise may also classify personal devices that can reach its resources as resources.
  2. All communication is secured regardless of network location: requests from inside the corporate network must meet the same security requirements as requests from any other network, and a device is not trusted just because it sits on the corporate network.
  3. Access to individual resources is granted per session: trust in the requester is evaluated before access is granted, with only the least privilege needed for the task; authenticating and being authorized for one resource does not automatically grant access to another.
  4. Access is determined by dynamic policy: based on the identity of the user or service, the application, the state of the requesting device, and other behavioral and environmental attributes.
  5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets: no asset is inherently trusted; devices with known vulnerabilities or that the enterprise does not manage may be treated differently, up to denial of all connections.
  6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed: this requires identity, credential and access management (ICAM) and asset management, with multi-factor authentication (MFA) for some or all resources; sessions are also monitored according to policy, with reauthentication and reauthorization where needed.
  7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

The three core components: who decides, who enforces

NIST splits the core of a zero trust architecture into three logical components[2]:

  • Policy engine (PE): makes the final decision on whether a subject may access a resource. It applies enterprise policy plus external input such as continuous diagnostics and mitigation systems and threat intelligence, runs a trust algorithm to grant, deny or revoke access, and logs the decision.
  • Policy administrator (PA): executes the policy engine's decision by establishing or shutting down the path between subject and resource, and generates the session-specific authentication token or credential.
  • Policy enforcement point (PEP): enables, monitors and, when needed, terminates connections between a subject and a resource. It can be split into a client side (for example, an agent on a laptop) and a resource side (for example, a gateway in front of the resource), or be a single portal.

NIST uses airport security to illustrate the traditional approach: once passengers clear the checkpoint, everyone in the boarding area is treated as trusted; zero trust moves the decision and enforcement points as close to the resource as possible and keeps this "implicit trust zone" as small as possible[2]. In plain terms, the policy engine is the person who reviews the request, the policy administrator is the one who issues the pass and opens or shuts the door, and the policy enforcement point is the guard standing at every door.

CISA's Zero Trust Maturity Model: five pillars to see where you stand

NIST explains what zero trust is; the Zero Trust Maturity Model (ZTMM) from the US Cybersecurity and Infrastructure Security Agency (CISA) is for assessing how far an organization has come. The current version is 2.0, published in April 2023[3]. It was designed to help US federal agencies plan zero trust under Executive Order 14028, but CISA says all organizations should review and consider adopting its approaches[3].

The model is made up of five pillars and three cross-cutting capabilities: the pillars are Identity, Devices, Networks, Applications and Workloads, and Data, and the cross-cutting capabilities are Visibility and Analytics, Automation and Orchestration, and Governance[3].

Each pillar has four maturity stages: Traditional, Initial, Advanced and Optimal[3]. The Traditional stage is marked by manual configuration, static policies, pillars working in silos, and least privilege set only once at provisioning; Initial starts automating attribute assignment and policy decisions, with early cross-pillar integration; Advanced uses automated controls where applicable with cross-pillar coordination, centralized visibility and identity control, and adjusts least privilege based on risk and posture; Optimal is fully automated, just-in-time dynamic least privilege with continuous monitoring[3]. Three functions show the difference[3]:

  • Authentication: Traditional uses passwords or MFA with static access; Initial uses MFA (passwords may be one factor) and validates several attributes such as locale or activity; Advanced begins authenticating all identities with phishing-resistant MFA, including initial passwordless MFA via FIDO2 or PIV smart cards; Optimal continuously validates identity with phishing-resistant MFA throughout access, not just at sign-in.
  • Network segmentation: Traditional relies on a large perimeter or macro-segmentation with few restrictions inside segments, and may depend on VPN tunnels carrying bulk traffic; Initial begins isolating critical workloads; Optimal uses microsegmentation built around application profiles, with just-in-time, just-enough connectivity.
  • Accessible applications: Traditional makes critical applications available only over private networks or protected connections such as VPN; Initial makes some critical applications available over open public networks to authorized users with need, via brokered connections.

CISA stresses that each pillar can progress at its own pace, that zero trust is an incremental process that may take years, and that it often adds cost at first[3]. In practice: map your current state onto the five pillars, find which stage each pillar is at, then pick the one or two pillars the business needs most and set the next-stage target, rather than chasing "Optimal everywhere" at once.

Note that CISA's web page for the model has been moved to its "Archived Content" section, with a notice that archived material may not reflect current policy or programs[4]. The 2.0 document is still available, however, and the zero trust guide for government agencies published by Taiwan's Administration for Cyber Security and National Institute of Cyber Security uses its Initial stage as the reference for the required identity and device authentication functions[5].

NIST SP 1800-35: lessons from 19 example implementations

To see what zero trust looks like in practice, read SP 1800-35, Implementing a Zero Trust Architecture, from NIST's National Cybersecurity Center of Excellence (NCCoE). The practice guide was published in final form in June 2025: the NCCoE worked with 24 collaborators under cooperative research and development agreements to build 19 example ZTA implementations from commercially available technology, summarized best practices and lessons learned, and mapped zero trust principles and technologies to commonly used security standards and guidelines[6]. The examples cover enhanced identity governance (EIG), software-defined perimeter (SDP), microsegmentation and secure access service edge (SASE), and the web version maps them to NIST CSF 1.1 and 2.0 and SP 800-53 Rev. 5[7]; it pairs well with NIST CSF 2.0. The guide is not specific to federal agencies, but OT and IoT environments are out of scope[7].

For anyone buying products, the guide carries some important reminders[7]:

  • No single ZTA fits all: it has to be designed around the organization's requirements, risk tolerance and existing investments.
  • The NCCoE does not certify, validate or endorse products: the builds only demonstrate what the participants' technology can do, and organizations should decide for themselves which products best integrate with their existing tools.
  • The common obstacle is missing foundations: for example, the perception that zero trust suits only large organizations and needs heavy investment, rather than being a set of guiding principles for organizations of any size; or a lack of adequate asset inventory, defined user roles, and visibility into internal communications and usage patterns.

From its lab experience, the NCCoE recommends seven steps: discover and inventory the existing environment (hardware, software, applications, data and services); formulate deny-by-default, least-privilege access policies based on business needs; identify existing security capabilities and reuse as much as possible; close gaps with a risk-based approach based on the value of data, deciding how to segment; implement incrementally, starting from identity, credential and access management (ICAM) with risk-based MFA, plus endpoint protection that assesses device health and integrates with ICAM; verify that enforced policy matches defined policy and test it regularly across scenarios; and keep adapting as threats, the business, technology and regulations change[7].

Taiwan: government agencies and listed companies

Government agencies: identity authentication, device authentication, trust inference

Taiwan's government zero trust program stems from the sixth National Cybersecurity Development Program (2021–2024): it called for evaluating and introducing zero trust networks and piloting them to verify feasibility, with annual targets of two agencies adopting identity authentication in 2022, two adopting device authentication in 2023, and two adopting trust inference in 2024[8].

The National Institute of Cyber Security (NICS) explains that the government zero trust architecture follows NIST SP 800-207 and uses a resource portal-based deployment: all access to information systems, whether from inside or outside the network, must go through one "access gateway" that hides internal network paths with a reverse proxy, which plays the role of NIST's policy enforcement point; whether to allow access is decided by three core mechanisms[9]:

  • Identity authentication: multi-factor authentication and signed authentication assertions, using passwordless two-factor methods such as FIDO2.
  • Device authentication: devices are registered and authenticated with keys and certificates generated through a TPM or an agent, and device health (whether the operating system, antivirus and applications are updated, and whether configuration is compliant) is monitored continuously and converted into a trust level.
  • Trust inference: a trust score is calculated for each access from its context, including the identity authentication method, device authentication method, device health, IP address and sign-in time, and used to decide whether access is allowed.

On scope and timelines, NICS states that the Administration for Cyber Security under the Ministry of Digital Affairs (moda) planned funding to prioritize adoption by government agencies at cybersecurity responsibility level A[9]; moda's April 2024 progress-tracking report also records a plan for level-A agencies to complete adoption of zero trust identity authentication by the end of 2024[10]. The seventh National Cybersecurity Development Program (2025–2028) reports that pilots of all three mechanisms were completed at the Ministry of Culture and the Veterans Affairs Council between 2022 and 2024, and that 16 identity authentication products and 3 device authentication products passed functional conformance verification; the next phase is to guide central government agencies in adopting zero trust, develop adoption guidance for agencies, and first build identity authentication with zero trust tools as the basis for later device authentication and trust inference[11].

The Reference Guide for Government Agencies Adopting Zero Trust Architecture: Identity and Device Authentication, published by the Administration for Cyber Security and NICS in December 2024, states that the government's priority is identity and device authentication, with trust inference guidance to follow later; it recommends starting with privileged accounts on important systems, high-privilege accounts that can reach large amounts of personal or sensitive data, and accounts of people outside the agency, piloting on a small scale and then expanding based on the results[5]. NICS also verifies vendor products for zero trust functional conformance: in the list updated on 14 August 2026, four products had passed identity authentication, device authentication and trust inference verification; but the list notes that NICS tests only zero trust functionality, not the security of the products themselves, and that the list is only a reference for government agencies' deployments[12].

Keep the legal layers apart. In the Regulations on Classification of Cyber Security Responsibility Levels as amended on 7 January 2026, none of Annexes 1 to 10 (the obligations for government agencies and specific non-government agencies at each level, the system protection-level principles and the protection baseline) contains a zero trust item[13]. The Annex 10 protection baseline requires multi-factor authentication for access only for systems with a "high" protection requirement; "medium" and "basic" systems must identify and authenticate users and prohibit shared accounts[14]. In other words, the zero trust program above is a government policy for public agencies, not a legal obligation on ordinary companies; specific non-government agencies covered by the Cyber Security Management Act should go by the actual text of the regulations, explained in Taiwan's Cyber Security Management Act.

Listed companies: Article 22 asks you to "evaluate"

TWSE revised its Cybersecurity Control Guidelines for Listed and OTC Companies in November 2026; the comparison table of amendments is dated 9 November 2026 (ROC year 115)[15]. Three articles bear directly on zero trust[1]:

  • Article 22: companies should set rules for user password management, "and evaluate adopting a zero trust architecture (Zero Trust Architecture), such as multi-factor authentication, for core information systems". Before the revision (as Article 21) the wording was "multiple authentication technology"; the explanatory notes say the change draws on the identification and authentication, password management and multi-factor authentication requirements in the classification regulations' protection baseline, and on government and financial-sector zero trust policies[15].
  • Article 18: networks should be divided into separate logical domains according to service needs, with development, test and production environments separated; for core systems or areas holding sensitive data, companies "should further use microsegmentation technology to refine isolation boundaries".
  • Article 25: remote access needs a secure connection mechanism (such as VPN or VDI) together with multi-factor authentication, encrypted connections, least privilege, complete audit trails of user activity, monitoring of abnormal behavior, and security patching.

Article 22 says "evaluate", not "must adopt", and Article 44 lets companies adopt the guideline as appropriate to their industry, size and cybersecurity risk, unless laws or TWSE and TPEx rules provide otherwise[1]. Even so, keep a written record of the evaluation: which systems are core, how each one is signed in to, which already have MFA, and when the rest will get it. Other changes in the guideline are covered in TWSE cybersecurity control guideline.

A practical order of work for companies

Zero trust is not just for large enterprises; the NCCoE says plainly that it is a set of principles suitable for organizations of any size[7]. The order below combines advice from NIST, CISA and Taiwan's government guidance, and each step pays off on its own. Start with an inventory: NIST notes that the policy engine needs complete knowledge of assets, users and business processes to make decisions, and that incomplete knowledge most often results in legitimate business being blocked, with unknown "shadow IT" a particular problem[2]. Listing the core systems, who needs to reach them and from where is the precondition for every later step.

Step 1: identity, with SSO and phishing-resistant MFA

Connect cloud services, VPN and internal systems to a single identity provider (SSO) wherever possible, turn on MFA everywhere, and move administrators and core systems to phishing-resistant MFA such as FIDO2 or passkeys first. This matches the Advanced stage of CISA's identity pillar[3] and is where the NCCoE recommends starting[7]. For choosing and rolling out MFA, see the MFA rollout guide; for conditional access and admin accounts in Microsoft 365 and Google Workspace, see the cloud office security baseline; if Active Directory is your identity source, deal with AD and privileged account protection first, or the identity layer itself becomes the biggest hole.

Step 2: devices, admitting only managed and compliant ones

NIST's fifth tenet calls for continuous monitoring of device security posture, with devices that have known vulnerabilities or are unmanaged restricted or denied[2]. The NCCoE lists endpoint protection that assesses device health and integrates with the identity system as another foundational component of an initial deployment[7]. In practice, use endpoint management tools to know each device's state and let access policy take that state into account; the device health items in Taiwan's government architecture (operating system updates, antivirus updates, application updates, configuration compliance) make a good starting checklist[9].

Step 3: from "joining the whole network" to "per-application access"

The fundamental problem with VPN is that an attacker who connects with a compromised device or account may be able to reach every service on the organization's network[16]. Joint guidance from five agencies in the US, New Zealand and Canada notes that CISA has found more than 22 Known Exploited Vulnerabilities (KEVs) related to VPN compromise, and describes solutions built on granular access policies such as zero trust network access (ZTNA): ZTNA uses an access broker to verify user identity and policy rules, grants least-privilege access, and can check device security posture and enforce MFA[16]. The guidance also warns that moving off VPN takes planning and sequential implementation, and that during the transition organizations should prevent access to the control plane, use a dedicated management interface, patch and analyze VPN telemetry, and use MFA[16]. The NCCoE suggests a practical method: when moving from a full-device VPN to per-app tunnels, first keep the full tunnel and observe actual traffic, then enable only the traffic each user profile needs[7]. For hardening the VPN appliance itself, see the edge device hardening checklist.

Step 4: segment critical systems

The NCCoE observes that an organization still relying on perimeter defenses is effectively protecting all its resources behind a single perimeter firewall; moving to zero trust means splitting the infrastructure into smaller parts, putting critical resources in their own trust zones protected by an enforcement point, while lower-value resources can share a zone[7]. CISA's Initial stage likewise means isolating critical workloads[3], and Article 18 of the TWSE guideline recommends microsegmentation for core systems[1]. Start with the most important servers, databases and management interfaces; there is no need to microsegment the whole company at once.

Step 5: logging and continuous verification

NIST's seventh tenet calls for collecting as much information as possible about assets, networks and communications to improve policy[2], and CISA treats visibility and analytics as a capability running across all five pillars[3]. The NCCoE recommends regularly testing whether policy behaves as intended across scenarios: managed and unmanaged devices, authorized and unauthorized users, connections from inside the company and from the internet[7]. Centralize identity, device, access gateway and VPN logs; for retention periods and priorities, see the logging strategy.

Common pitfalls

  • Buying a product before the identity foundation is in place: NIST says plainly that zero trust cannot be achieved with a wholesale replacement of technology[2]. If accounts are still shared and administrators lack MFA, even an expensive gateway is only checking a password that may already be leaked. NICS's verification list likewise tests only zero trust functionality, not product security[12].
  • New front door, same flat network: the joint guidance notes that Volt Typhoon used VPN sessions with administrator credentials to move laterally through victim networks and blend in with normal traffic[16]. Replacing only the entry point with ZTNA while the internal network stays wide open means the damage still spreads once an attacker is in.
  • Vendor lock-in: zero trust draws on many data sources, and NIST warns that proprietary formats can lock an enterprise into a few providers; when evaluating vendors, weigh their security controls, switching costs and supply chain risk alongside the usual factors[2].
  • Policy scattered across products: the NCCoE found access rules often spread across endpoint, identity, network and data components, and recommends recording explicitly what each rule is and where it is configured[7].
  • The decision components become a new single point of failure: if the policy engine or administrator is compromised, misconfigured or unreachable, it may allow access it should not, or stop the whole business; restrict who can change its configuration, log and audit changes, and plan for redundancy[2].

Action checklist

  • Use NIST's seven tenets as a checklist and ask vendors to explain, tenet by tenet, which part their product covers and which existing components it depends on.
  • Inventory core systems, user roles and access sources, and write down who can currently reach which systems from where.
  • Self-assess your current stage on CISA's five pillars and set next-year targets for each pillar.
  • Connect all cloud services, VPN and core systems to SSO with MFA, moving administrators and high-privilege accounts to phishing-resistant MFA first; let only managed, compliant devices reach core systems.
  • Harden the existing VPN first, then pilot per-application access for one or two applications and expand after observing traffic.
  • Move core systems, databases and management interfaces into separate segments and allow only the connections they need.
  • Centralize identity, device and access logs, and test access policies quarterly against a fixed set of scenarios.
  • Listed companies: write up the Article 22 evaluation and include it in cybersecurity reports to the board or management.
  • If you need outside help with an inventory or gap assessment, see our security health check service.