3 questions from the package
From the RFI round. The first shows part of the guide each question carries; the workbook adds follow-ups, how to verify the answer, a priority and a weight.
1. Which of these conditions can a single access rule in your product combine to decide a request: user, group, application, source location, source network, URL category and time of day?
Why it matters. If a rule cannot combine identity with application and context, the buyer has to write broad rules or many duplicate ones, and users end up with access beyond what their role needs.
Good answer
- All listed conditions can be used together in one rule, with documented AND, OR and exclusion logic
- An application condition can be defined by host name, IP range, port and protocol, not only by subnet
- Source location can be defined as named offices or countries, not only as raw IP addresses
Red flags
- Conditions sit in separate policy layers that cannot be combined in one rule
- Private applications can only be defined as network ranges
- The vendor answers with a feature list and cannot show a combined rule
2. For TCP and for UDP separately, which port specifications can a private application definition in your product use: a single port, a list of ports, a port range or all ports?
Why it matters. If the broker carries only TCP, or only fixed ports, the buyer must keep the VPN for applications that use UDP or wide port ranges. The concentrator then cannot be retired.
3. For each agentless access method your product offers to devices that do not run your agent, such as a clientless browser proxy, an enterprise browser or browser-rendered RDP and SSH, which application protocols does that method carry?
Why it matters. Contractor, BYOD and acquired-company rollouts are planned on the assumption that agentless access reaches the applications those users need. An application outside a method's protocol set forces an agent install or keeps a VPN running for that user group.
Capability areas
Identity and per-application access policy (12)
How policy expresses user, group, application, location, network, category and time conditions to grant least-privilege access per application rather than per network: use of identity provider groups and how fast group changes take effect, step-up authentication per application, re-evaluation of open sessions when identity or risk changes, rule actions and evaluation order, what-if testing, and policy versions with comparison and rollback. Device posture signals are in DPC; generic SSO and SCIM connector availability is covered by the integration module.
Private application and protocol coverage (11)
Which private applications and protocols the broker carries without a side-channel VPN: full TCP and UDP, thick clients, RDP, SSH, SMB, Kerberos and NTLM authentication, server-to-client and client-to-client flows, private DNS resolution, and discovery of the applications users actually reach. Web-gateway inspection of internet traffic is out of scope.
Unmanaged device and agentless access (8)
Browser-based, clientless or enterprise-browser access for contractors, BYOD and acquired-company users, what that method covers and does not cover, and the session controls available, such as copy, download and print restrictions. Posture handling for devices that can run an agent is covered in DPC.
Device posture and continuous context (9)
Device-health and compliance signals from the agent and from EDR, MDM and UEM integrations, how often posture is re-checked during a session, risk scoring, the action taken when posture changes, and the approach for OT and IoT devices that cannot run an agent or report posture.
App connectors and private application publishing (9)
Deployment of inside-out connectors that make only outbound connections, connector sizing guidance, high availability and failover between connectors, connector health monitoring, segmentation between connector groups, and the effect on access if the broker or a connector becomes unavailable. The vendor's corporate disaster recovery program is out of scope and is covered by the business continuity module.
Traffic steering, endpoint agent and edge network (14)
How traffic reaches the service: the endpoint agent on and off the corporate network, IPsec and GRE tunnels from sites, PAC files, point-of-presence selection and failover, fail-open and fail-closed behavior, bypass lists, IPv6 handling, dedicated egress IPs and local egress, agent tamper protection and staged updates, coexistence with other endpoint agents, and the latency added for chatty applications. Hosting regions and tenancy are out of scope and are covered by the deployment and hosting module.
Web filtering and TLS inspection (14)
URL category filtering and actions, category lookup and recategorization, classification of uncategorized and newly registered domains, custom allow and block lists, safe search, warning and block pages, DNS filtering, TLS decryption including TLS 1.3, decryption exemptions, origin certificate validation, handling of pinned applications, and decryption coverage reporting.
Threat protection and browser isolation (9)
Malware scanning of downloads, including nested and password-protected archives, sandboxing with hold or deliver choices, phishing and credential-harvesting detection, malicious script blocking, command-and-control blocking for non-browser processes, true file-type control, import of the buyer's threat indicators, remote browser isolation, and false-detection reporting.
Cloud application control and data protection (10)
Discovery and risk attributes of cloud applications, activity-level controls, separation of corporate and personal instances, generative AI application control, DLP on web uploads, form posts, AI prompts and private application traffic, exact data match and fingerprinting, OCR, evidence storage, and reuse of existing DLP policies. The vendor's own handling of buyer data is out of scope and is covered by the data protection module.
Access logging, investigation and experience monitoring (10)
Content of private-access and web transaction logs, search across a time range, the delay before a transaction becomes searchable, per-user investigation timelines, dashboards and scheduled reports, streaming to a SIEM or to storage the buyer controls, pseudonymized identities, and digital-experience monitoring that traces the user-to-application path for troubleshooting.
Platform coherence, administration and universal ZTNA (9)
Whether private access, web gateway, cloud application control and DLP share one policy engine, one agent and one console; policy-as-code for access and web policies; propagation of a policy change to every point of presence and agent; administrator roles scoped by function and by application, group or location; change audit with before and after values that administrators cannot edit; operational alerting; and extension of the same policy to campus and branch users alongside NAC and SD-WAN. Policy versioning and rollback are in POL; generic API availability and SSO are covered by the integration module.
