Skip to main content

// Symantec · ZTNA

Symantec ZTNA (Zero Trust Network Access)
implementation, migration, support.

Symantec ZTNA - historically Secure Access Cloud - gives users access to specific internal applications instead of a flat VPN network. It is the cleanest way to retire legacy VPN concentrators and adopt Zero Trust principles for hybrid work. CyberKIS deploys ZTNA for organizations replacing aging VPN infrastructure or modernizing toward SSE.

Also known as: Symantec ZTNA · Secure Access Cloud (legacy) · SaC

// 01 · Implementer perspective

What you need to know,
from someone who has shipped it.

ZTNA is conceptually simple and operationally subtle. The core idea: instead of giving a user network-level access ("you are on the corp LAN, do whatever you can route to"), give them application-level access ("you can access exactly these 6 apps, with policy checks per session"). The hard parts are real:

App discovery is the bottleneck. Most organizations don't have an accurate list of internal apps. CyberKIS spends the first 2-3 weeks of every ZTNA project just discovering apps via DNS logs, VPN session logs, and stakeholder interviews. Skipping this leads to missed apps and angry users in week one of cutover.

RDP / SSH / database access matters more than web. Most ZTNA marketing focuses on web apps. The harder use cases - RDP to internal servers, SSH to bastion hosts, direct database client access - are where organizations actually need ZTNA. Symantec ZTNA supports all of these; CyberKIS designs the connector / agent strategy.

Identity is non-negotiable. ZTNA requires a working IdP. If your AD / Entra integration is broken or your groups are messy, fix that BEFORE rolling out ZTNA. We have walked away from projects where the customer wanted ZTNA without fixing identity - it doesn't work.

VPN retirement is a 6-12 month project, not a cutover. You run VPN and ZTNA in parallel for months, migrate user populations and apps in waves, and only decommission VPN when the last app is on ZTNA. Plan accordingly.

// 02 · Capabilities

Full coverage of the
ZTNA platform.

We deploy and support every capability listed below - not just the headline features.

  • 01 Application-layer access (per-app, not network-layer)
  • 02 Identity-driven policy via Okta, Entra, Ping, Azure AD
  • 03 Device posture checks (encryption, AV state, OS version)
  • 04 Agent and clientless (browser-only) access modes
  • 05 Web app, RDP, SSH, database protocol support
  • 06 Integration with Cloud SWG, CloudSOC, and Symantec DLP for consistent SSE policy
  • 07 No inbound firewall ports required (outbound-only architecture)
03. // Migration paths

01

Cisco AnyConnect / ASA VPN Symantec ZTNA

The most common ZTNA project. Application inventory, policy design per app, phased user migration, VPN decommission. 6-9 months for a 5,000-user environment.

02

Palo Alto GlobalProtect Symantec ZTNA

Usually driven by Symantec / Broadcom contract consolidation or SSE platform unification.

03

Zscaler Private Access (ZPA) Symantec ZTNA

Rare; usually driven by enterprise standardization on Symantec stack across Cloud SWG, CASB, and ZTNA.

Typical timeline: Pilot 3-4 weeks. Full enterprise rollout: 6-9 months for a 5,000-user environment with 20-50 internal apps.

// 04 · Use cases

The engagements we
actually ship.

A non-exhaustive list of the scenarios that come up most often in CyberKIS ZTNA projects.

  • Retiring legacy VPN concentrators (AnyConnect, GlobalProtect, FortiVPN)
  • Contractor / third-party access to specific internal apps
  • Merger and acquisition: temporary cross-org access without network merge
  • Hybrid work expansion: secure internal app access from anywhere
  • Compliance: per-app access logging and policy enforcement
  • BYOD: clientless browser-only access for unmanaged devices

// 05 · FAQ

Real questions,
honest answers.

What buyers ask before scoping a ZTNA project.

  • 01

    How is ZTNA different from a VPN?

    +

    A VPN gives you network access - once connected you are "on the LAN" and can reach anything routable. ZTNA gives you application access - you authenticate to a specific app, get a session for that app, and cannot see or reach anything else. The difference matters during a breach: a compromised VPN credential is a network-wide problem; a compromised ZTNA credential is one-app problem.

  • 02

    Does Symantec ZTNA support RDP and SSH?

    +

    Yes - both with agent and clientless modes. Clientless RDP and SSH run through a browser-based session; with agent mode, native RDP / SSH clients connect through the ZTNA tunnel. CyberKIS configures both depending on use case (admins typically want native clients, contractors get clientless).

  • 03

    Can we use Symantec ZTNA with Okta / Entra / Ping?

    +

    Yes. ZTNA is identity-driven by design - it requires an IdP for user context and policy evaluation. Symantec ZTNA supports Okta, Microsoft Entra (Azure AD), Ping, and SAML IdPs generally. The IdP also drives group-based policy (e.g., "Engineering group can access GitLab Enterprise; Sales cannot").

  • 04

    Can ZTNA fully replace VPN?

    +

    For most use cases, yes. A few legacy protocols (custom UDP, certain VoIP, multicast applications) don't map cleanly to ZTNA and need a different solution - but those are increasingly rare. For 90%+ of remote-access use cases, ZTNA is the modern replacement. Realistic timeline: 6-12 months from start to VPN decommission for a typical enterprise.

  • 05

    What about contractors and third-party access?

    +

    This is one of the best ZTNA use cases. Instead of issuing a contractor a VPN account (broad network access) plus an MFA token, you give them a ZTNA account scoped to exactly the 2-3 apps they need. Access expires automatically when the contract ends. Audit log shows exactly what they touched.

06. // Pairs well with

// Get started

Ready to deploy
ZTNA?

Tell us your environment, current state, and timeline. We will come back with a fixed-scope plan.