Reference · built on requestOperator by FibricIT & reliability

MFA Gaps

Reads second-factor enrollment in Okta, Entra ID, Google Workspace, and AWS, weighs it against admin roles, and proposes deadlines.

Request accessPricing ↗

About

A second factor is enforced by policy, and policy has gaps: accounts created before the rule, break-glass admins, service users with a password and no device. MFA Gaps reads what each system records about enrollment. In Okta, the factors enrolled per user and their status. In Microsoft Entra ID, the userRegistrationDetails report with isMfaRegistered, isMfaCapable, and isAdmin. In Google Workspace, isEnrolledIn2Sv and isEnforcedIn2Sv. In AWS, the mfa_active column of the credential report.

It ranks uncovered accounts by the roles they hold, admins first, and proposes a deadline for each. A person approves the deadlines and the notices that carry them. After a deadline passes it proposes the next step you have chosen, such as suspension, as a separate approval.

This is a reference listing. It documents what Fibric would read from MFA Gaps and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Enrolled factors per Okta user through GET /api/v1/users/{userId}/factors, with factorType such as push, token:software:totp, webauthn, or sms, and status ACTIVE or PENDING_ACTIVATION
  • userRegistrationDetails from Microsoft Graph: isMfaRegistered, isMfaCapable, isPasswordlessCapable, methodsRegistered, isAdmin, and userType member or guest
  • isEnrolledIn2Sv, isEnforcedIn2Sv, isAdmin, and isDelegatedAdmin on Google Workspace users through the Directory API
  • mfa_active, password_enabled, and access_key_1_active per user in the AWS IAM credential report
  • GitHub organization members returned by GET /orgs/{org}/members with filter=2fa_disabled
  • Admin role holders in each system, read from Okta admin roles, Entra ID directory roles, and Google Workspace roleAssignments

Proposed actions

  • Target capability: propose an enrollment deadline per uncovered account, ordered by role, delivered as a Slack or Teams message to the person and their manager
  • Target capability: propose a Jira issue per admin account without a second factor, with the system, the role, and the deadline
  • Target capability: propose Reset factors through POST /api/v1/users/{id}/lifecycle/reset_factors for an Okta user whose enrollment is stuck in PENDING_ACTIVATION
  • Target capability: propose the follow-up you configured for accounts past deadline, such as Suspend a user in Okta or suspended true in Google Workspace

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Put a date on every admin without a second factor

    Okta users holding an admin role with no ACTIVE factor, and Entra users with isAdmin true and isMfaCapable false, get a proposed deadline and a Jira issue each. Approving the batch sends the notices.

    With Okta, Microsoft Entra ID, Jira

  • Close the gap in a Google Workspace domain

    Users with isEnrolledIn2Sv false in an org unit where enforcement is due get a proposed Slack notice with the date. After the date, a proposed suspension list is sent for a second approval.

    With Google Workspace, Slack

  • Find GitHub members without two-factor

    Members returned by the 2fa_disabled filter are matched to the HR roster and their identity provider record. Each gets a proposed deadline notice, and organization owners get one proposal listing them.

    With GitHub, Slack

Requirements

  • Okta API scopes to read users and factors, or Microsoft Graph permissions for the authentication methods report, or Google Admin SDK Directory read scopes
  • For AWS, iam:GenerateCredentialReport and iam:GetCredentialReport
  • A messaging connector such as Slack or Microsoft Teams for deadline notices, or Jira where you prefer an issue per account
  • Your own deadline policy: how long admins get, how long everyone else gets, and what happens after
Authentication
Reads enrollment with the identity connectors' read scopes and sends notices through the messaging connector you attach. Suspensions use the identity connector's write scope only when you approve them.

Limits

  • Okta lists only factors REQUIRED or OPTIONAL in the user's highest priority enrollment policy, and an admin's own client conditions can change which policy applies.
  • Entra's isMfaRegistered counts methods the policy may not allow. isMfaCapable is the stricter test, and the report carries a lastUpdatedDateTime rather than being live.
  • Google Workspace exposes isEnrolledIn2Sv as read only. Enrollment happens in the user's own account, so the operator sets a deadline but cannot enroll for them.
  • The AWS credential report refreshes at most every four hours and covers IAM users only. Roles and federated identities carry no mfa_active column.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request MFA Gaps ↗

Questions and answers

What does a person approve?
A batch of deadlines: each account, the system, the role that set its priority, the date, and the notice text. You change dates, remove accounts, or reword the notice before approving. Any follow-up after a deadline is a separate proposal, approved on its own.
What record is left?
Per account, the enrollment state read from the system and when, the deadline, the notice sent and to whom, who approved, and the state read again at the deadline. Accounts that enrolled in time show the factor and the date.
Can it enroll a factor or turn enforcement on?
No. Enrollment is done by the account holder in their own system. Enforcement settings in Okta, Entra ID, or Google Workspace are not touched. It proposes deadlines, notices, issues, and, if you configure it, a suspension after the date.
Ask about MFA Gaps

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy