Okta

AccessPeople

Access & Identity

Mycroft reads Okta users, groups and application assignments to build the account inventory behind access reviews, and tests MFA, password and session policy.

Okta answers who has access to what, and its deactivation events give offboarding a measurable clock. Accounts in other connected systems are reconciled against the Okta roster, and any without a matching identity are surfaced as orphans.

Find out more

How Mycroft connects to Okta

How it connects: You create an Okta OAuth service app and authorize it against your org. The grant includes offline_access so the connection refreshes itself.
What Mycroft can access: Read-only, and narrower than Okta's full management API: the granted scopes are okta.users.read and okta.authenticators.read.

Which controls Okta evidence maps to

Each row is a control an auditor tests and the specific artifact Mycroft collects from Okta to satisfy it. Collection runs on a schedule and every result is timestamped.

Okta compliance control mappings and the evidence Mycroft collects for each
Framework	Control	What it requires	Evidence collected from Okta
SOC 2	CC6.1	Logical access controls restrict access to information assets.	Full user, group and application assignment inventory, with MFA policy configuration and per-user enrolled factors.
SOC 2	CC6.2	Registration and authorization precede credential issuance; access is reviewed.	User creation and activation events from the Okta system log, matched to the hire date in your HRIS, plus the completed access review record for each account.
SOC 2	CC6.3	Access is granted on least privilege and removed when no longer needed.	Deactivation and suspension events with timestamps, and the measured interval to removal of each downstream account, giving an offboarding interval that is computed rather than asserted.
SOC 2	CC6.7	Authentication protects against unauthorized access.	Password policy settings (length, complexity, history, lockout), session lifetime and idle timeout, and MFA enforcement per application and per group.
ISO 27001	A.5.16	Identity management covers the full identity lifecycle.	Lifecycle event history for every identity (created, activated, suspended, deactivated) with the actor and timestamp for each transition.
ISO 27001	A.5.17	Authentication information is allocated and managed securely.	Enrolled factor inventory per user, factor policy configuration, and identification of users without a second factor.
ISO 27001	A.5.18	Access rights are provisioned, reviewed and revoked.	Periodic access review records: reviewer, accounts reviewed, decisions, exceptions raised and the date completed.
ISO 27001	A.8.2	Privileged access rights are restricted and controlled.	Inventory of Okta super administrators and other admin role holders, with MFA state and last sign-in for each.
HIPAA	§164.308(a)(3)(ii)(C)	Procedures terminate access when workforce membership ends.	Termination-to-deactivation interval for every departure, reconciled against the HRIS termination date.
HIPAA	§164.312(a)(2)(i)	Unique user identification is assigned and used.	Account inventory showing one identity per person, with shared and generic accounts flagged for exception handling.

What Mycroft collects automatically

Gathered from Okta on a schedule, dated and stored against the controls above.

Complete user roster with status, groups, application assignments and last sign-in
MFA policy configuration and per-user enrolled factors, including users with none
Password policy: length, complexity, history, expiry and lockout thresholds
Session lifetime and idle timeout settings per policy
Admin role holders (super admin, org admin, app admin) with MFA state
Provisioning and deprovisioning events with actor and timestamp
Dormant accounts identified by last-sign-in age against your threshold
Orphaned downstream accounts with no matching Okta identity

Manual work this removes

The tasks that disappear from someone's quarter once Okta is connected.

Exporting the user list, distributing it to managers and chasing responses each quarter
Cross-referencing the leaver list against Okta to confirm access was removed in time
Screenshotting MFA and password policy settings for each audit
Searching for accounts in other systems with no matching identity
Compiling the administrator list by hand

Often connected alongside:

All integrations →

Okta and Mycroft: frequently asked questions

The user roster and the authenticators each person has enrolled. Those are the two granted scopes, okta.users.read and okta.authenticators.read, and they are what the account inventory behind access reviews is built from. Mycroft starts building that inventory on the first sync after the connection is authorized.

No. The integration is read-only by design. Mycroft can see that an account exists and what it can reach, and it records when your administrators deactivate someone, but revocation stays with your team. That separation keeps Mycroft an evidence system rather than another privileged tool in your environment.

Mycroft assembles the current account list across every connected system, groups accounts by the person who owns them using Okta as the identity source, and routes each reviewer only their own people. Reviewers approve or flag; flagged items become remediation tasks; the completed review with reviewer, decision and date is stored as evidence for SOC 2 CC6.2 and CC6.3 and ISO 27001 A.5.18.

An account in a downstream system (an IAM user in AWS, a collaborator on a GitHub repository) with no matching identity in Okta. It matters because nobody owns it, nobody reviews it, and it usually outlives the person who created it. Reconciling downstream accounts against the Okta roster is how those get found before an incident finds them.

No. The Okta connection is granted okta.users.read and okta.authenticators.read only, plus offline_access so it can refresh. That covers the user roster and enrolled authenticators; it does not include the system log.

We turn the compliance nightmare into a dream

Talk to us