Identity and Device Trust in Zero Trust Access

A valid username does not tell you which device is requesting access, and an enrolled device does not tell you whether the person using it should be authorized for a sensitive resource.

ZTXGate treats user identity and device identity as related but distinct policy signals.

That lets access decisions consider who the user is, which endpoint they are using, what is known about that endpoint, what they want to reach, and what the current policy allows.

User Identity: Who Is Asking?​

ZTXGate can integrate with existing identity systems rather than requiring every organization to maintain a completely separate identity lifecycle.

OIDC for Authentication and Identity Claims​

OpenID Connect can be used to authenticate a user through a compatible identity provider and provide identity claims to ZTXGate.

This establishes who the user is. It does not automatically define every resource that user should be allowed to reach.

SCIM for Provisioning and Lifecycle​

SCIM can synchronize user and group lifecycle information from supported identity systems.

That helps access follow organizational changes as users join, change roles, or leave.

OIDC and SCIM solve different problems:

OIDC  → authentication and identity claims
SCIM  → provisioning and identity lifecycle

Device Identity: Which Endpoint Is Asking?​

ZTXGate enrolls user devices individually.

A laptop, phone, tablet, or other endpoint can therefore be represented separately in policy rather than every device belonging to one user being treated as interchangeable.

If one endpoint is lost, retired, or no longer trusted, administrators can revoke that device without necessarily disabling the user's other enrolled endpoints.

Device Posture: What Do We Know About the Endpoint?​

Device identity answers which endpoint is making the request. Device posture can add information about the endpoint's current state.

For connected environments, ZTXGate supports posture integrations including:

• Microsoft Intune
• Microsoft Defender for Endpoint
• SentinelOne Singularity
• CrowdStrike
• Jamf

Available compliance or risk information can become another policy signal when deciding whether a protected resource should be accessible.

Posture integrations depend on connectivity to the corresponding service.

Identity + Device + Resource + Context​

A Zero Trust access decision becomes more useful when these signals are evaluated together.

For example, a policy may allow a user to reach a production resource only when:

1. the user belongs to the appropriate role
2. the endpoint is enrolled
3. the available device posture satisfies policy
4. the request falls within an allowed time window
5. explicit approval has been granted
6. required step-up authentication has been completed

Another resource can use a simpler policy.

The goal is not to maximize friction. It is to make the level of verification match the sensitivity of the resource.

Integrated ZTXBAS with ZTXGate​

ZTXBAS has two distinct product uses.

Inside ZTXGate​

When the ZTXBAS capability is licensed with ZTXGate, it is tightly integrated as a library and does not need to be deployed as a separate ZTXBAS server.

This integrated model works across ZTXGate deployment types, including fully air-gapped environments.

That gives ZTXGate an authentication option that does not depend on reaching an Internet-hosted push service.

Standalone ZTXBAS​

ZTXBAS is also available as a free standalone product for developers who want to integrate biometric authentication directly into their own applications without using ZTXGate.

That standalone product has its own server/application integration model.

Explore standalone ZTXBAS

External Authentication Options​

Connected ZTXGate deployments can also use supported authentication services such as:

• Okta Verify Push
• Duo Push

These services remain dependent on connectivity to their respective cloud platforms.

That distinction matters in disconnected environments: integrated ZTXBAS remains available while an Internet-hosted authentication service is available only when the network intentionally permits access to it.

Continuous Policy Enforcement​

Identity and device state are not necessarily static for the duration of a session.

A user's role can change. A temporary access window can expire. A posture condition can change.

ZTXGate can continue evaluating relevant policy conditions after access begins and revoke access when those conditions no longer satisfy the configured policy.

Device Enrollment Is Not the Same as MDM​

ZTXGate device enrollment establishes an endpoint identity for ZTXGate access.

An MDM or EDR platform can provide additional posture or risk context where integrated and reachable.

These are complementary functions:

An organization can use the signals appropriate to its deployment model.

Connected and Air-Gapped Environments​

In a connected environment, ZTXGate can use cloud identity, posture, monitoring, or authentication services where required.

In a fully air-gapped environment, those external cloud services are unavailable unless the architecture intentionally provides connectivity to them.

ZTXGate's core access operation does not depend on those external services. When licensed, integrated ZTXBAS also remains available in the isolated deployment for phishing-resistant biometric authentication.

Audit Identity and Device Context​

Access records become more useful when they retain the context around the decision.

ZTXGate records access, authentication, and policy activity so administrators can investigate which identity and device were involved and how access was handled.

Relevant events can also be exported to supported monitoring environments where connectivity exists.

A Better Access Question​

Instead of asking only:

Did this user authenticate?

ZTXGate can ask:

Is this user, on this device, under these conditions, authorized for this resource now?

That is the relationship between identity and device trust in the ZTXGate access model.

Explore the full ZTNA architecture