Alright, let's cut through the usual "best practice" fluff. I'm seeing a lot of threads praising dynamic policies for contractors, but they're missing the forest for the trees. The assumption is always that the tags are applied correctly and the contractors' devices are actually known and manageable. That's a heroic assumption, especially if you're trying to retrofit this onto an existing messy environment.
The real trick isn't just setting up the tag-based policy in FortiSASE. It's ensuring the tag gets onto the device reliably in the first place, and that the policy you apply is meaningfully stricter. Most orgs I've seen just create a slightly different web filtering profile and call it a day, which is security theater. If a contractor's device is truly untrusted, your policy should be draconian: client certificate authentication for internal apps, full tunnel with no split-tunneling to their sketchy home network, and aggressive application control that blocks everything except the three SaaS tools they absolutely need.
Start by asking how the contractor device gets the 'contractor' tag. Is it pushed via the FortiClient EMS that you, somehow, have installed and managing on their personal laptop? Good luck with that. More likely, you're relying on them to manually join a contractor SSID or VPN group that assigns the tag. That's a gap right there. Then, your dynamic policy must reference that tag. The policy sequence matters—make sure it's evaluated before any broader, more permissive policies.
And let's be honest, this often fails because of the "set and forget" mentality. You build this beautiful, strict policy for contractors, but then someone from HR needs a temp to access some legacy HR system that requires a relaxed rule. What happens? An exception is carved out, or worse, the temp gets added to a regular employee group. The policy decays. The real guide should be about governance: who can change tags, who can modify the dynamic policies, and how you audit exceptions. Without that, your fancy tag system is just a more complicated way to have the same porous security you started with.
—jake
Your mileage will vary
Totally agree, especially about the tag application being the real challenge. We had a similar scenario when migrating our contractors to a new workspace setup. The theory of pushing tags via EMS was perfect, but in practice, getting that agent on a device we don't own was a non-starter half the time.
We ended up using a different attribute for the tag, based on the user group in our identity provider. That way, it didn't depend on the device state at all. But then you run into your point about the policy needing to be truly strict. If the tag is user-based, you're essentially trusting the network they're on anyway.
What did you do for contractors who outright refused any agent installation? Did you just fall back to a captive portal with heavier restrictions?
Migration is never smooth.
Yeah, you've hit on the core issue. That tag application step is where everything falls apart. We had the same fight trying to use EMS tags for a BYOD program.
Our workaround was a hybrid approach that still makes me cringe a little. We use *both*:
* A user-group-based tag from the IdP for initial, basic access (heavier web filter, no split tunneling).
* A separate, much stricter policy triggered by an actual EMS tag, but that policy grants access to the sensitive internal apps. No EMS tag, no internal access. It's clunky, but it got us past the "no agent" blocker for basic contractor tasks.
The policy part is key though. If your "contractor" policy still allows split-tunneling to their home router, you've basically accomplished nothing.
Data is the new oil - but it's usually crude.
Agreed. The tag application part is always glossed over in guides.
What happens if the tag fails? Does the contractor just get the default, more permissive user policy, or do they get no access at all? I'm trying to set this up and that's the part that's unclear from the documentation. It seems like a single point of failure.