Update src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx

Co-authored-by: hyperlint-ai[bot] <154288675+hyperlint-ai[bot]@users.noreply.github.com>

Author: securitypedant

src/content/docs/reference-architecture/design-guides/designing-ztna-access-policies.mdx

@@ -481,7 +481,7 @@ As mentioned before, private IP applications work because Cloudflare proxies the
 | **Action**                               | Allow                                                           |
 | **Enforce WARP client session duration** | 60m0s                                                           |
 
-Defining the application here is simple, as Cloudflare automatically fills in the IP range, and you need to limit the detected protocol to RDP. However, the rules for private IP applications are slightly different. You’ll notice they appear as network policies under the Cloudflare Gateway menu, despite managing them in Access. Certain options, such as checking for MFA and external evaluation, do not appear here. However, these attributes can be verified when the user activates their device client and authenticates to their organization.
+Defining the application here is simple, as Cloudflare automatically fills in the IP range, and you need to limit the detected protocol to RDP. However, the rules for private IP applications are slightly different. You'll notice they appear as network policies under the Cloudflare Gateway menu, despite managing them in Access. Certain options, such as checking for MFA and external evaluation, do not appear here. However, these attributes can be verified when the user activates their device client and authenticates to their organization.
 
 One option available here is enforcing the device agent client session duration. This means that after a certain amount of time, the user will be forced to reauthenticate. This feature allows you to take a Zero Trust approach to protecting private IP applications as well; it ensures that even if a user's credentials are compromised or their device is left unattended, the potential window for unauthorized access is limited. By regularly requiring reauthentication, we're continuously verifying the user's identity and authorization status, aligning with the core Zero Trust principle of "never trust, always verify."