ZTNA vs IAM: why identity comes first

IAM and ZTNA in one paragraph each

Identity and access management (IAM) is the system of record for people and accounts: an identity provider that authenticates users, single sign-on (SSO) to applications, multi-factor authentication (MFA), and the processes that create, change and remove accounts as people join, move and leave. Identity governance adds reviews of who has access to what.

Zero trust network access (ZTNA) is an enforcement layer. It takes the identity the IAM system has proven, combines it with device identity, device health and behaviour, and decides per application whether a network connection should be brokered. It does not store your users or decide what roles exist; it relies on the identity provider for that.

What each does

Why the NCSC puts identity first

The NCSC's ZTNA guidance has a whole section on what to do before building a ZTNA architecture. For identity it expects:

• an authoritative identity provider acting as the single source of truth
• strong, phishing-resistant authentication, such as FIDO2 credentials, applied consistently through single sign-on
• defined processes for creating, modifying and removing accounts, with prompt de-provisioning when access is no longer needed
• defined user roles, identity signals that can inform access decisions, and centrally logged identity activity

It sets equivalent expectations for devices: a hardware-bound device identity, typically using a TPM, central device management, baseline security and posture visibility, and monitoring. Two of the NCSC's four ZTNA signal types, user identity and device identity, come straight from these foundations, and the NCSC's zero trust design principles include "Know your user, service and device identities". Our NCSC zero trust principles page covers the full set.

What goes wrong when ZTNA sits on weak identity

ZTNA does exactly what its policy says, using the identity it is given. Common failures:

• Leavers keep access. If accounts are not disabled promptly, ZTNA faithfully lets a former employee or contractor in.
• Group sprawl. Policies built on groups are only as accurate as group membership. Years of ad hoc additions mean the policy grants more than intended.
• Phishable MFA. If an attacker can relay a one-time code or push approval, they arrive with a valid identity and a valid session.
• Shared and service accounts used interactively, which makes per-user policy and logging meaningless.
• Admin accounts used for everyday work, so a single phished session carries privileged rights.
• Unmanaged devices treated as managed because device identity was not established.

None of these is fixed by buying a ZTNA platform. They are fixed in the identity layer, ideally before or alongside the ZTNA rollout.

Identity, MFA and device trust in practice

Common building blocks, with examples from platforms we supply:

• Identity providers. Microsoft Entra ID and Okta are widely supported sources of identity for ZTNA policy, usually connected over SAML or OIDC, with SCIM provisioning where the ZTNA platform supports it.
• MFA and device trust. Cisco Duo adds MFA and device checks in front of applications and VPNs. Duo device trust confirms a device is managed and, on higher editions, checks health such as disk encryption, firewall and OS version.
• Identity in the access platform. Exium IAM360 is Exium's identity module, providing SSO, MFA, passwordless sign-in, identity brokering and a password manager alongside Exium SASE.
• Risk-informed access. Some platforms let identity risk change access. Trend Micro ZTSA can use risk data from the Vision One platform to restrict a risky user or device, and Cisco Secure Access can show identity risk from Cisco Identity Intelligence and, in some packages, use it in private access policy.
• MFA before admin access. Zero Networks keeps privileged ports closed until the user completes MFA through your identity provider.

For the broader picture of protecting accounts and sign-ins, see identity security on our cloud security site.

How ZTNA uses identity signals

Once the identity layer is sound, ZTNA can use it well:

• Groups and roles map to application access, so a finance user reaches finance systems and nothing else.
• Authentication strength can be a condition: phishing-resistant MFA for sensitive applications, ordinary MFA for others.
• Device identity and posture add a second check, so a valid user on an unknown or unhealthy device gets less, or nothing.
• Continuous re-evaluation means a disabled account, a risk change or a device falling out of compliance can end a session rather than wait for the next sign-in.
• Central logging of identity and access decisions gives investigators both halves of the story.

The broader concept of access where nothing is trusted by default is covered on what is zero trust access.

Two kinds of policy engine: where IAM and ZTNA overlap

The NCSC's signals and policy engines guidance makes the overlap explicit. It describes two kinds of policy engine:

• Network-level, which controls which network destinations a client can reach. The NCSC's examples are VPN-as-a-service, SSE and SASE: this is where ZTNA products sit.
• Application-level, which authorises access to a specific application, often provided by an identity provider or SSO service, issuing a short-lived token the client presents to the application.

The NCSC does not prescribe one or the other; organisations may use one or both. Used together, the network-level engine limits which segments and applications are reachable at all, and the identity provider's conditional access then authorises the specific application during sign-in. For SaaS applications, where you do not control the network, the identity layer carries most of the weight.

Privileged access: IAM, PAM and ZTNA together

Administrators are where weak identity hurts most, and where several controls meet:

• Privileged access management (PAM) vaults admin credentials and brokers sessions. KeeperPAM, for example, includes Keeper Connection Manager for browser-based RDP, SSH, VNC and database sessions without handing out the underlying passwords.
• Identity segmentation limits where admin and service accounts can log on at all. Zero Networks Identity Segmentation restricts each account to the assets and logon types it needs, with just-in-time MFA for privileged access.
• ZTNA decides whether the admin's device may reach the management interface in the first place, and keeps that interface off the internet.

The NCSC's expectation of phishing-resistant authentication matters most here. Remote desktop and admin access options are compared on secure remote desktop access.

The order of work

A sensible sequence for most organisations:

1. Consolidate on one authoritative identity provider and tidy accounts, groups and roles.
2. Enforce MFA everywhere, moving to phishing-resistant methods for administrators and sensitive systems.
3. Fix joiner, mover and leaver processes so access follows employment status promptly.
4. Bring devices under management and establish device identity and posture checks.
5. Then deploy ZTNA, building policy on the groups and device signals you now trust.

Steps can overlap, and a ZTNA pilot often exposes identity problems usefully early. Our how to implement zero trust network access guide expands each phase.

How Forever Systems helps

We can assess your identity and device foundations against the NCSC prerequisites, recommend what to fix before or during a ZTNA rollout, and supply MFA, device trust and ZTNA licences from several vendors. Scope is confirmed at quote; ask us for a quote. Contact us to start with a readiness conversation.