We're in the process of rolling out Prisma Access to replace a legacy VPN for our engineering and support teams. The mandate from leadership is to support BYOD (Bring Your Own Device) for approved personal laptops, but the security team is (rightfully) paranoid about lateral movement and data exfiltration. The classic model of "you're either fully on the network or fully off" doesn't work here. We need to allow access to specific internal apps (like the dev wiki, internal tooling portals, and non-prod Kubernetes API endpoints) without giving these personal devices a route to our core financial or customer data networks.
Our current working design uses Prisma Access with Explicit Proxy and a heavy dose of Service Principals. The idea is that personal devices never get a traditional VPN config. Instead, they get a PAC file or manual proxy configuration that points to our Prisma Access Explicit Proxy endpoints. Authentication is handled per-application via SAML to our IdP (Okta), and we're using Prisma's User-ID and Security Policy rules to lock down what these devices can do.
Here's a snippet of the Terraform we're using to define the security policy for the "contractor-device" group. This is the critical partβallowing only specific FQDNs and categorizations, and forcing all traffic through the Prisma cloud proxy.
```hcl
resource "prismacloud_policy" "byod_engineering_access" {
name = "BYOD Engineering Baseline Access"
policy_type = "config"
cloud_type = "all"
rule {
name = "Allow approved SaaS and internal apps"
criteria = "config from cloud.type = * AND (resource.type = host) AND (user.role = 'byod-engineer')"
parameters = {
traffic_direction = "EGRESS"
service = "http-proxy, https-proxy"
destination = "saas-applications, business-systems"
action = "allow"
profile = "prisma-access-profiles/default-web"
}
}
rule {
name = "Block all other traffic"
criteria = "config from cloud.type = * AND (resource.type = host) AND (user.role = 'byod-engineer')"
parameters = {
traffic_direction = "EGRESS"
service = "any"
action = "deny"
}
}
}
```
The implementation challenges we're hitting are:
* **Application Discovery:** Building the initial list of "allowed" FQDNs for internal apps is a manual nightmare. We're leaning on Prisma's SaaS Security and DLP to monitor outbound traffic from corporate devices to build a baseline, but it's slow.
* **Client Configuration:** Distributing and enforcing the proxy configuration on unmanaged personal devices. We're providing detailed docs and a one-time setup helper script, but it's a support burden.
* **Kubernetes Access:** For non-prod cluster access (`kubectl`), we're using `kubectl proxy` through the explicit proxy, which is clunky. Considering ArgoCD or a dedicated dashboard as a gateway instead.
What I want to know from others who've done this:
* Did you use Explicit Proxy, or did you go with a clientless access model (Prisma Access SASE)?
* How did you handle the initial "allow list" creation for internal applications without breaking productivity?
* Are you using any additional posture checks (like CrowdStrike or Tanium) on the personal devices before allowing them to authenticate, even just for the proxy? We're considering a simple check for disk encryption and an OS version minimum via an Okta workflow before adding the user to the `byod-engineer` group.
* Is anyone using this model and also providing limited access to development VPCs via Prisma Access? How did you segment that traffic from the corporate traffic?
Automate everything. Twice.
Been down a similar path with our own dev contractor access. The explicit proxy route is solid, honestly. One thing we learned the hard way was to be absolutely meticulous about the PAC file distribution - if a user can bypass it and just point their browser at the proxy IP/port, your auth might still catch it, but you've created a shadow path.
We ended up pairing the proxy config with a mandatory, lightweight MDM profile (even for BYOD) that just enforced the proxy settings and certificate install. It gave us an extra bit of assurance the intended controls were actually in place before a session even started.
Also, test your SAML sessions with Incognito windows relentlessly. That IdP session persistence can sometimes create unexpected "always on" states that the security team will hate. Fine-tuning those session timeouts on a per-application basis in Okta was key for us.
customer first