The Okta security features you're paying for but not using

Having a control is not the same as using it

This is the pattern we see most often. An org licenses Adaptive MFA, or turns on Behavior Detection, or defines a Device Assurance policy, or draws up Network Zones, and then assumes the work is done. It is not. Each of those only changes a sign-in when a policy rule references it. Left at its default, the feature sits there fully paid for and does nothing. A static compliance checklist will happily tick "MFA: yes" and miss all of it, because the checklist asks whether a feature exists, not whether anything uses it.

Adaptive MFA risk scoring, entitled but never enforced

Okta's risk engine scores every sign-in when your subscription includes risk-based authentication. But policy rules only act on that score through the "Risk is" condition, and that condition defaults to Any. So out of the box, a sign-in Okta itself scored high risk is allowed under exactly the same requirements as a routine one. You are paying for the risk evaluation and throwing away the verdict. Atomation flags when no active Global Session or app sign-on rule sets a Low, Medium, or High risk condition, so that free signal turns into an actual control instead of a line item on the invoice.

Behavior Detection, configured but not referenced

Behavior Detection is the classic "set up and forgotten" feature. Admins define the behaviors — new device, new location, velocity, new IP or ASN — and never attach them to a policy rule. The behaviors are active, they cost nothing extra to reference, and they influence exactly zero sign-in decisions. Atomation reports when Behavior Detection is configured but no active policy rule uses it, so it can start doing the adaptive step-up it was meant to.

Device Assurance and Network Zones, defined but not applied

The same shape shows up in device and network posture. A Device Assurance policy that no authentication or access policy references does not gate anything. A Network Zone that is defined but never used in a Global Session or app sign-on rule is just a saved list of IP ranges. Both look like progress on a dashboard and change nothing at sign-in. We surface each one as a defined-but-unapplied gap, with the object as evidence, so you can either wire it into a policy or retire it deliberately.

This is a cost story too

The flip side of "licensed but unused" is money. If you are paying for a tier because of a capability you never enforce, that is a renewal conversation. Surfacing what you own versus what you actually use lets you either switch the feature on and get the value, or right-size the license and stop paying for a control that is doing nothing. Either outcome is better than the status quo of paying for both the seatbelt and the airbag and wearing neither.

Why our checks are license-aware, not a static list

Here is the part that makes this honest rather than noisy: some of these controls we cannot even assess unless your org is licensed for them, and we detect that read-only. If your subscription does not include risk-based authentication, for example, the "Risk is" condition will not do anything no matter how you set it — so telling you to configure it would be wrong. Instead we detect whether the entitlement is present and adjust: if you are licensed and not using it, we call that out; if you are not licensed, we do not pretend the control is broken, we explain why the capability is worth having and leave the buying decision to you. The assessment adapts to what your org actually has, every scan, so it stays accurate as you turn features on and off.

You cannot fix what a checklist never noticed. Point Atomation at your org and see what is licensed or configured but not actually enforced. The demo is open, no signup: demo.atomation.io.