Skip to content

Commit d7f1e67

Browse files
committed
update header
1 parent 5aceb70 commit d7f1e67

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/content/docs/learning-paths/zero-trust-web-access/concepts/clientless-access.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ IT/security admins can decide how users authenticate, whether through their corp
1616

1717
A device client enables additional capabilities for a ZTNA deployment, like adding full device posture checks to policy evaluations or providing access to private network resources on private hostnames. However, when extending access to third-party or temporary workers, some organizations are reluctant to buy and ship company-managed devices or onboard clients to users' personal devices. Some IT or security teams may have rigorous device compatibility, interoperability, or other software audit processes that could delay user onboarding for a ZTNA rollout. Contractors may also not allow external company software to be installed on their personal devices, whether a legacy VPN or a more modern software client.
1818

19-
### Identity provider integration
19+
### Identity provider workarounds
2020

2121
Some organizations historically have created corporate identities for third-party users within their internal identity provider, or they have spent the time to integrate a third-party's external identity provider with their own. Time and complexity for this work aside, not all resources integrate directly with traditional identity and access management (IAM) products, so a tool like ZTNA can still be needed to aggregate access logistics more broadly across an organization's internal resources.
2222

0 commit comments

Comments
 (0)