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.