
Admit the right device. Connect the right user to the right application.
NAC controls admission to your local network. ZTNA controls access to specific applications. TRILOGY scopes the two decisions separately, then aligns identity, device conditions and access policy where the architecture requires both.
When this solution is relevant
Employee and guest network access
Define admission rules for managed devices, guests and exceptions.
Device segmentation
Apply agreed policies to device classes and network zones.
Remote application access
Connect authorized users to defined private applications.
Third-party access
Limit external access by application, identity and approved conditions.
Technology options
Technology options to evaluate against your requirement. Product capabilities, editions and integrations are confirmed in the agreed configuration.
NAC — local-network admission
Cisco — Identity Services Engine — ISE
- Centralized identity-based access for wired, wireless and supported VPN environments
- Device profiling and posture inform authorization decisions
- TrustSec and integrations can support segmentation workflows
Fortinet — FortiNAC
- Device discovery and network access policy enforcement
- Posture-based responses through supported network integrations
- Security Fabric integrations connect visibility to enforcement

HPE Aruba Networking — ClearPass Policy Manager
- Role-based access policies across multi-vendor networks
- Authentication and authorization informed by user and device context
- Guest and onboarding workflows depend on selected ClearPass components
ZTNA — application access
Netskope — Netskope One Private Access
- Least-privilege access to authorized private applications
- Universal ZTNA covers supported remote and on-premises access scenarios
- Client, connector and third-party access modes are selected by requirement

Palo Alto Networks — Prisma Access
- ZTNA policies for user-to-application access
- Continuous trust checks and supported traffic inspection
- Part of the wider SASE/SSE architecture with separately scoped capabilities
Zscaler — Zscaler Private Access — ZPA
- Private application access through identity and contextual policies
- Application connectors reduce direct application exposure
- Deployment architecture includes available service-edge options
Names and trademarks belong to their owners.
What we verify
Device classification
Accuracy of tested device profiles against a known inventory.
Admission outcomes
Results of allowed, denied, guest and exception scenarios.
Application reachability
Permitted access and blocked paths for the tested applications.
Policy traceability
Identity and device condition linked to the access decision.
How the technical work is scoped
01
Scope and architecture
Define the assets, integrations, ownership and acceptance criteria before selecting the configuration.
02
Implementation and change
Configure the agreed controls through an approved change plan, with rollback steps and assigned responsibilities.
03
Verification and handover
Test agreed scenarios, record exceptions and hand over the configuration, operating procedures and test evidence.

Technical scope in detail
NAC prerequisites
Switch, wireless, identity and certificate capabilities are reviewed before enforcement. A pilot validates 802.1X, fallback and supported profiling methods. Unsupported endpoints receive explicit exceptions.
Segmentation design
Device classes are mapped to the necessary services and zones. Enforcement is tested at the actual network control points. The design records dependencies that must remain reachable.
ZTNA application publishing
Applications are inventoried by protocol, location and authentication method. Connectors and access policies are deployed only for supported scenarios. Tests confirm that permitted access does not expose unnecessary network paths.
Device posture and identity
Available identity and device signals determine policy conditions. A missing posture signal is not treated as proof of device health. Exception behavior and re-evaluation are documented.
Controlled rollout
Observation and pilot stages precede broader enforcement. Tests include certificate failure, connector failure and emergency access. Handover documents user support and rollback procedures.
Licensing and sizing
For NAC, review managed endpoints, network-device compatibility and policy features. For ZTNA, review licensed users, application protocols, connectors, locations and device-posture integrations.
What to share with us
Network topology and device types; identity/certificate systems; private applications and remote users.
What you receive
Agreed scope and architecture
Selected configuration and integration record
Approved change and rollback plan
Test record and documented exceptions
Operating procedures and technical handover
Frequently asked questions
Are NAC and ZTNA interchangeable?
No. Their enforcement points and access decisions differ. Some environments need both.
Can ZTNA replace every VPN use case?
Application protocols, administrative access, legacy systems and connectivity requirements must be checked before replacement.
Does an SSE classification evaluate NAC?
No. SSE is a separate analyst category. It must not be presented as an evaluation of a NAC product.
Discuss the requirement
Tell us what you need to protect, change or recover. We will use the details to define the next technical discussion.
Prefer to talk? Call +966591909277
