Are you using what you already have?
Your Okta org is full of capability: features that come included, add-ons you license, and controls you already configured. Atomation reads what is actually there on every scan and shows what is off, what nothing enforces, and what your users have not adopted yet.
- Okta Verify number matchingSecurityEnabled
- Phishing-resistant authenticationSecurityWorth enabling
- CAPTCHA on sign-inSecurityWorth enabling
- Self-service recovery optionsEnd-userReview for your org
The three ways capability you already have goes missing.
A capability only counts when it is present, a policy uses it, and your people are actually enrolled. The scan checks all three — for every feature, Early Access or GA, included or licensed.
The adoption layer is the one most reviews never see. Say Okta Verify is enabled and FastPass is set to optional: that configuration is not the finding. The finding is that 38% of your active users have never enrolled — with the recommended step to drive adoption and consider making it required. And if your environment has a real reason to keep it optional, you resolve the finding as not applicable with the reason documented. Either way, the decision is deliberate and on record.
Features present in your org — Early Access or GA, including security hardening that comes included — sitting disabled. The scan inventories them and flags the ones worth turning on.
The capability exists, included or licensed, but no policy actually uses it. Risk scoring you own while every policy still ignores the risk signal is the classic case.
The control is on, enrollment is optional, and a share of your users never enrolled. The finding reports the exact share and the practical step that drives adoption.
From a settings page nobody opens to a view your team can act on.
The raw feature list in the Okta Admin Console is a wall of toggles. The scan turns it into three layers your team can actually use.
Every scan reads your org's actual feature list — what exists, what is enabled, and what stage each feature is in. No generic checklist; your org's list is the starting point.
Each feature carries a plain-language recommendation: enable it, review it for your environment, or no strong opinion. Every recommendation says why in one line.
When a security-hardening option is available but switched off, it becomes an advisory finding with framework mapping — ready for the report, not buried in a settings page.
Seven areas, so the right owner sees the right features.
Security and threat protection, authentication and access, administration, end-user experience, provisioning and integration, governance and monitoring, and AI and agents. Your security lead reads one group; your app owners read another.
Recommendations are tiered, and respectful of your decisions.
Not every off switch is a problem. Some features are disabled deliberately, some are mid-rollout, and some are genuinely missed. The tiers keep those apart so the report reads as guidance your team can stand behind, not a list of accusations.
When a finding does not fit your business, you resolve it as not applicable or accepted, with the reason documented. The scan cannot know why your policies are set up the way they are — the finding makes sure the choice is deliberate and on record, which is exactly what an auditor wants to see.
Recommended for every org. Low-risk hardening with no real downside — the scan flags these when they are off.
A security enhancement worth enabling where it applies — things like number matching, CAPTCHA, and phishing-resistant options.
Depends on your environment. The scan surfaces it with context so your team can decide — some features are off on purpose, and that is a decision worth documenting, not a failure.
No strong opinion either way. Listed in the inventory so nothing is invisible, never nagged about.
Free hardening first, license questions second.
Some of the strongest improvements cost nothing: security options that ship with your org and are simply switched off. The scan flags those first. And for the capabilities you license separately, the assessment checks whether they are actually enforced by a policy — because paying for a control that no policy uses is the most expensive kind of off.
Read more: The Okta security features you're paying for but not using.
Enable something new, and the next scan knows.
Feature lists change as Okta rolls capabilities out and as your team turns things on. Every scan reflects the current list, so the guidance stays matched to your org — and when a new feature unlocks new checks, they activate automatically on the next run.
The same goes the other way: when your org is not licensed for a capability at all, the checks that depend on it are skipped, not failed. The engine works out what your org actually has and holds you only to what is achievable.
See your org's feature posture.
Connect read-only and your first scan returns the inventory, the recommendations, and the findings — grouped, tiered, and ready to act on.