Zero Trust Security: Principles, ZTNA, and Adoption Stages

Why Zero Trust?

Traditional perimeter security models start from the premise that “the internal network is safe.” That premise has collapsed with the shift to the cloud, the spread of remote work, and the rise of insider threats. The 2020 SolarWinds attack and the 2021 Colonial Pipeline incident both exposed the limits of perimeter security.

Zero Trust is the principle of “Never Trust, Always Verify.”

Three Core Principles

1. Verify Explicitly Every access request is verified holistically: user identity, device state, location, and time zone. Combine MFA + device certificates + behavioral analysis rather than simple password authentication.

2. Least Privilege Grant only the minimum privileges required for the job, and re-verify those privileges per session. For AWS IAM, apply resource-level policies instead of wildcard (*) policies.

3. Assume Breach Design as if the interior is already compromised. Block lateral movement with microsegmentation and encrypt all traffic.

Implementation Roadmap

Phase 1: Asset Identification (1–2 months)

• Inventory all users, devices, apps, and data
• Classify critical data and analyze access patterns

Phase 2: Build the Policy Engine (2–3 months)

• Integrate an IdP (Identity Provider): Okta, Azure AD, Google Workspace
• Device management: MDM/EDR integration (Intune, CrowdStrike)
• Design conditional access policies

# example: Azure AD
conditions:
  users: all_users
  cloud_apps: all_apps
  device_state:
    require_compliant: true
  sign_in_risk: medium_or_above
grant_controls:
  operator: AND
  mfa_required: true
  compliant_device: true

Phase 3: Network Microsegmentation

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Phase 4: Continuous Monitoring

• Integrate with SIEM to detect anomalous access patterns
• Adopt User and Entity Behavior Analytics (UEBA)
• Retain access logs for 90 days or more

Conclusion

Zero Trust is a strategy, not a product. Big tech firms such as Microsoft and Google have already rolled it out company-wide. In Korea, adoption is accelerating in finance and the public sector as ISMS-P certification requirements tighten.

How ZTNA Replaces VPN

The network implementation of Zero Trust is ZTNA (Zero Trust Network Access). The differences from traditional VPN are the key.

VPN trusts everything “inside the tunnel,” but ZTNA evaluates policy for every user–device–app combination.

The Korean Adoption Context

• KISA published Zero Trust Guideline 2.0, which presents a maturity model and adoption stages.
• Public-sector and financial institutions must apply this alongside network-separation regulations, so it is more realistic to design ZTNA as a complement and modernization of network separation—not a replacement.

Common Failure Patterns

• Stopping at MFA — MFA alone, without device-state and context verification, is not Zero Trust.
• Skipping segmentation — Strengthening identity verification without blocking lateral movement means damage still spreads after a breach.
• Big-bang cutover — Trying to apply it company-wide at once paralyzes operations. Phased rollout starting with critical apps is the standard approach.

When Access Breaks After a Policy Rollout: Cause, Verification, Fix

The most common incident during a zero trust rollout is not a breach but legitimate users suddenly being denied.

Causes

• Device posture conditions (OS version, EDR present, disk encryption) are enforced but some devices fail to report compliance
• Non-human principals such as service accounts and batch jobs hit MFA conditions
• IdP group sync lag leaves new hires or transferred staff out of policy scope

Verification order

1. Check the denial reason in the IdP sign-in logs (e.g., Microsoft Entra ID sign-in logs, policy evaluation in the Okta System Log).
2. Check the denied device's compliance state in the MDM console.
3. To rule out network path issues, confirm the same user can connect from a compliant device.

# e.g. policy denials for one user in the Okta System Log
curl -s -H "Authorization: SSWS $OKTA_TOKEN" \
  "https://<org>.okta.com/api/v1/logs?filter=actor.alternateId+eq+%22user@corp.com%22+and+outcome.result+eq+%22DENY%22"

Fix and staged enforcement

• Run new policies in report-only mode for one to two weeks to see which users and devices are affected, then enforce.
• Separate service accounts from human policies and replace them with workload identities (managed identities, short-lived tokens) plus source restrictions.
• Keep two break-glass accounts and alert immediately whenever one is used.

Prevention

• Manage policy changes through tickets and change history, and alert when the denial rate spikes above baseline.

Frequently Asked Questions (FAQ)

Q. If we adopt Zero Trust, do we have to drop VPN immediately? No. Most organizations run ZTNA and VPN in parallel and migrate app by app. Leave legacy apps on VPN and move new/critical apps to ZTNA first.

Q. Do small companies need Zero Trust too? The principles (MFA, least privilege, logging) apply regardless of size. Instead of a full-stack ZTNA product, start with IdP (MFA) + cloud conditional access for cost efficiency.

Editor’s Note — From the Field

Zero Trust is closer to organizational politics than “buy a product and you’re done.” The biggest resistance isn’t technical—it’s departments asking “why are you cutting my privileges?” Successful rollouts almost always start small, like “MFA on admin accounts + one critical system,” show results, then expand. Company-wide big-bang almost always fails. Design the order of “who to persuade first” as carefully as the technical roadmap.

References

• NIST SP 800-207: Zero Trust Architecture
• Kubernetes Network Policies