Having spent more cycles than I care to admit untangling the policy spaghetti of post-merger networks and failed "cloud transformation" projects, I have to say the premise of this question makes me twitch. Asking for the "best way" to structure policies in a SASE context is like asking for the best way to organize a toolbox: it entirely depends on whether you're fixing a watch or a bulldozer, and more importantly, who you're trying to keep from stealing your tools.
The real answer is that any single-dimensional policy structure—whether you pick groups, devices, or locations as your primary key—will fail you within 18 months. It becomes a taxonomic nightmare. You'll end up with "Sales-NorthAmerica-Contractor-iPhone" as a group because your model couldn't reconcile overlapping attributes. FortiSASE, like any major platform, gives you these levers, but the architecture matters more than the individual knobs.
My strongly-held, somewhat sardonic advice is to build a **hybrid model with a clear hierarchy of trust**, and then be ruthlessly consistent. Here's the flawed logic of each single approach:
* **Pure User/Group-Based:** The Salesforce admin's dream. "Marketing gets access to these web apps, Finance to these." It falls apart when Marketing is working from a coffee shop in Lisbon on a personal tablet versus their managed laptop in the office. The context of the device and location *must* modulate that access.
* **Pure Device-Based:** The old-school network team's comfort zone. "All corporate-managed devices get X policy." This ignores the fact that your CFO's corporate laptop and an intern's corporate laptop shouldn't have identical access, even if the hardware profile is identical.
* **Pure Location-Based:** "On-network: high trust; Off-network: low trust." This is obsolete. The "network" is now the internet. A hotel WiFi in a major city is not inherently less secure than a home WiFi, and both are wildly different from a branch office SD-WAN tunnel.
So, what's the less-bad way? You need a multi-factor policy matrix. Start with **Identity as the primary anchor**, then let **Device Posture** and **Requested Location** act as dynamic modifiers.
1. **Your core policies are defined for user groups** (e.g., "Engineering," "Third-Party Contractors").
2. **Layer in device trust.** A policy for "Engineering" should have a clause for "on a Fortinet-enrolled, encrypted, patch-compliant device" that grants broader access, and a separate clause for "any other device" that triggers step-up auth and restricts to basic web apps.
3. **Use location as a risk signal, not a gate.** A login attempt from a never-before-seen country on a new device for a high-privilege account should trigger a block or heavy MFA, regardless of group. But location alone shouldn't be the sole determinant of access.
The pitfall I see constantly is teams building three separate policy trees that eventually contradict. The console lets you do it, so they do. The operational cost of maintaining that—and the inevitable security gaps that open up when a new app needs provisioning and someone takes a shortcut—is a silent budget killer.
Start with the question: "What is the minimum level of access this identity needs to perform their function, and how do we ratchet that down when the context is risky?" Build your policy objects and rules to answer that, not to fit neatly into a single column of a spreadsheet.
-- Carl
Test the migration.
I'm harperk, a senior growth engineer at a 600-person SaaS company, and I handle the auth and feature-flag policies that govern access for our internal teams and tiered customers. I push live policy changes daily via Okta and a custom flag system.
**Policy clarity vs. debugging overhead:** A pure user-group model wins on readability for product teams. The cost is tracing inheritance when a request is denied, which adds 15-20 minutes to every support ticket. A location-first model has the opposite problem: easy to debug, but a nightmare to map business logic onto.
**Change velocity and blast radius:** Using device posture as your top-tier gate is safest for a zero-trust rebuild. In our rollout, device-check failures blocked only 7% of traffic but eliminated 95% of our weird BYOD shadow IT risks. The trade-off is it takes us ~3 hours to propagate a new device compliance rule to all endpoints.
**The hidden merge conflict:** Any two-dimensional policy (user + location, device + group) creates rule collision. We use a precedence order: identity > device > location. Without that, you'll spend a Friday afternoon manually resolving which of the 12 applicable policies actually gets enforced for your CEO's home laptop.
**Long-term taxonomy debt:** Start with groups and you'll have 300+ within a year. Start with locations and you'll be defining "Austin-Conference-Room-B" as a network object. We enforce a naming convention (team:project:environment) and a quarterly policy purge, which still eats half a sprint of engineering time.
I'd recommend starting with user/group as your primary axis if you're a product-led SaaS company, because access maps directly to features. If you're in a regulated industry or just survived a breach, start with device compliance as your top-level gate. To decide, tell us how many distinct "sensitive" data categories you have and whether your CISO reports to the CEO or to engineering.
Data over dogma.
Ah, the good old "precedence order" solution. We tried that with AWS Service Control Policies, and it's a trap that looks great on a whiteboard but creates a hidden financial audit trail.
Your `identity > device > location` chain means a policy higher up the stack can silently whitelist a mountain of unintended resources. We once had an identity-based rule for contractors that, due to precedence, overrode a location-based S3 bucket policy. Result? Six months of `us-east-1` data egress from a contractor's dev script, billed at the standard rate instead of the discounted cross-region rate we'd negotiated. The policy engine said "allowed," and no one ever saw the location check fail.
That debugging overhead you mentioned? Multiply it by 100 when you have to trace not just *why* access was denied, but *why* an expensive operation was allowed. Your precedence order needs a companion "cost attribution" log, otherwise Finance will have questions your security logs can't answer.
Exactly. This is why precedence becomes a liability without an explicit decision log. The policy engine's "allowed" verdict is a boolean that erases the entire evaluation context. What you need in your log stream isn't just the outcome, but the *path*: a record of every evaluated rule, its match state, and the precedence weight that made it the winner.
We built this by adding a sidecar service to our policy decider that writes a structured audit event. For every request, it captures not just the final allow/deny, but an array of the top three contending rules and their attributes. That's how you answer Finance's question: you can query for all allowed accesses where a location-based rule was matched but overridden by a higher-precedence identity rule. It turns a hidden override into a reportable condition.
Without that, you're flying blind on cost attribution. Your S3 egress example is perfect-it's a policy shadow cost that never appears in a security dashboard.
connected
Great point on the decision log. That audit trail is exactly what gets lost when we rely on Jira tickets for policy changes - you see the final status but not the rationale behind overridden rules.
Do you have any tips for rolling this out without overwhelming teams with data? I can see the value, but I worry about creating log fatigue.