Hey everyone! 👋 Still pretty new to Appgate SDP and I'm trying to lock down our setup.
We have a bunch of policies for general access, but I need to add MFA only for the high-risk ones (like accessing our financial servers). I don't want to force MFA for everyone on every policy—just the sensitive ones.
I've been poking around the Admin UI. I see where to set up the MFA provider globally, but I'm stuck on how to bind it to specific policies. Do I create a new Condition? Or is it in the Policy itself under "Entitlements"?
Maybe a screenshot of where this setting lives would help? Or a quick config snippet if you do it via CLI/API?
Thanks for any pointers! This community has been super helpful so far.
I think you're on the right track looking at Conditions. That's where I'd start. You can create a condition that checks for, say, a tag like "high-risk" on the policy or the target. Then you apply your MFA requirement to policies matching that condition.
I'm still learning the Appgate UI myself. When you set the MFA provider globally, does it give you an option to assign it at the policy level in the entitlements section, or is it only a system-wide toggle? That part always confuses me a bit.
Let me know what you find. I'm setting up something similar for our sales data access and might be a step behind you.
The policy itself is where you'll find the MFA setting, not in the entitlements. Once you have a global provider configured, you edit the specific high-risk policy and look for the authentication section - you'll see a dropdown to require the MFA claim.
Conditions can get you partway there for scoping, but the actual enforcement is a per-policy checkbox. Just make sure your MFA provider is returning the correct claim your condition checks for, otherwise you'll have a nice, useless policy.
Data skeptic, not a data cynic.
That's right. The MFA provider has to be globally configured first. Then you go into each policy's authentication settings.
The dropdown for "Require MFA" is under Policy > Advanced (or sometimes Authentication). It's a simple toggle, not tied to entitlements.
One gotcha: if your MFA provider's claim mapping is wrong, the policy won't actually enforce MFA. I've seen that happen with a misconfigured Okta rule.
—cp
Great question! You're close. The global MFA setup is step one, but then you go into each policy to turn it on.
Edit your high-risk policy. Look in the "Authentication" tab, not Entitlements. You should see a dropdown or checkbox for "Require MFA claim". That's the specific toggle for that policy. No need for a separate Condition unless you're doing something super complex.
Quick tip: after you enable it, test the policy with a test user. It's easy to miss a step in the claim mapping from your IdP, and you'll want to catch that before going live. Let us know if you find that setting!
Keep it simple.
Ah, that's really helpful. I was definitely overthinking it with the Conditions route.
The testing tip is key - I can see myself getting the toggle set and assuming it's working. Setting up a test user first makes so much sense. Do you typically just add a claim manually for that test, or do you actually hook it into the MFA provider from the start? I'm worried about misconfiguring the real IdP during the test phase.
I've been setting up similar policies recently. You're right to look for it in the Admin UI - the toggle is indeed in each policy's configuration.
What helped me visualize it was:
- Edit your "financial servers" policy
- Go to the "Authentication" tab (or section labeled "Claims")
- There's a specific dropdown called **Require MFA Claim**
The global setup is just making the provider available. The actual enforcement is that per-policy toggle. It's simpler than messing with Conditions for basic MFA gating.
For testing, I'd suggest making a duplicate of your real policy with a different name, enable MFA on the duplicate, and test with a small user group. That way you don't risk locking anyone out of the production access while you verify the claim mapping works. The UI doesn't always make it obvious when MFA is silently failing because of claim issues. 😅
Clean code is not an option, it's a sanity measure.
Totally agree on the duplicate policy for testing - that's saved me so many times. What I'd add is to make sure your test policy uses the same identity provider settings, not just a copy-paste. Sometimes the claim mapping gets weird if the IdP config isn't identical.
Also, watch your admin audit logs while testing. You can see the MFA claim being evaluated (or missing) in real time, which is way faster than waiting for user reports. The UI might not flag it, but the logs usually tell the truth 😅
One more thing: if you're using tags to group high-risk policies, you can test the MFA toggle on one, then quickly apply the same change to others with similar tags using the API. Saves clicking through each one.
K8s enthusiast