MFA Enforcement at Org Level

MFA reduces credential-theft impact. The org-level enforcement.

SCP

Multi-factor authentication is the single security control with the highest ROI in 2026. Compromised passwords are still the dominant initial-access vector for breaches; MFA closes that vector for any account that has it enabled. Enforcing MFA universally requires layered controls because no single layer catches every case.

The first layer: AWS SCP enforcement.

• AWS SCP denying actions without MFA.: Service Control Policies in AWS Organizations can deny specific actions when the calling identity has not authenticated with MFA. The policy attaches at the organization or organizational-unit level; every account in scope inherits the constraint.
• Catches at API time.: The SCP evaluation happens on every API call. Even if a user got authenticated without MFA somehow, their actions get denied at the API layer. The control is enforced regardless of how the session was established.
• Critical actions specifically.: The SCP often targets specific high-risk actions: IAM modifications, key deletions, billing changes, organizational changes. The MFA requirement applies to the dangerous operations; routine read operations may not require it.
• Cross-account consistency.: Multi-account architectures use SCPs to enforce MFA uniformly across accounts. Without SCP, each account has to be configured separately; with SCP, the policy applies to the entire organization.
• aws:MultiFactorAuthPresent condition.: The condition key that drives SCP MFA enforcement. Policies use it to gate actions; the condition is evaluated per request based on the session's MFA state.

SCP enforcement is the AWS-specific layer. Equivalent mechanisms exist in GCP (Organization Policies) and Azure (Conditional Access policies); the principle generalizes.

IdP

The second layer is at the identity provider. Okta, Azure AD, Google Workspace, and other IDPs can require MFA at login. The IDP enforcement catches MFA-less authentication attempts before any session is established.

• IDP enforces MFA at login.: The IDP requires MFA as part of the authentication flow. Without it, the login fails. The user cannot proceed to any application without satisfying the MFA requirement.
• Catches at session start.: The IDP enforcement happens at session creation time. Once the session exists with MFA verified, downstream applications trust the session. The check is upstream of every application access.
• Conditional access for context.: Modern IDPs support conditional access: require MFA based on the request's context (location, device, risk score). High-risk contexts (new device, new country, suspicious behavior) require MFA; low-risk contexts may allow remembered MFA.
• Step-up authentication.: The IDP can require MFA again for sensitive operations even within an active session. Accessing the admin console requires fresh MFA; accessing the user's own profile may not. The step-up matches the operation's sensitivity.
• FIDO2 hardware keys preferred.: Hardware security keys (YubiKey, Titan, Apple Touch ID, Windows Hello) provide phishing-resistant MFA. SMS and TOTP MFA can be defeated by sophisticated phishing; hardware keys cannot. Modern IDPs default to hardware-key MFA where available.

IDP enforcement is the broader layer. Combined with SCP for cloud-specific dangerous operations, the two layers cover most of the MFA enforcement surface.

Audit

The third leg is auditing. Defining MFA requirements is necessary but not sufficient; verifying that they are actually applied requires continuous audit. The audit catches the cases where MFA enforcement has gaps.

• MFA-enabled rate per principal.: Track the percentage of accounts that have MFA enabled. The metric is per-IDP, per-cloud, per-application. Targets are 100% for privileged accounts; 95%+ for all accounts. Anything below the target gets investigated.
• Target 100% for privileged accounts.: Admin accounts, accounts with broad cloud permissions, accounts that can access sensitive data. These cannot have MFA optional; the enforcement must be unconditional. Any privileged account without MFA is a finding.
• Trends over time.: The MFA coverage rate should trend upward over time. New accounts get MFA from day one; existing accounts get MFA enforcement applied. The trajectory is the leading indicator of program maturity.
• Per-application audit.: Some applications integrate with the IDP and inherit MFA; some do not. The per-application audit identifies the gaps. Applications without MFA enforcement get migrated to use the IDP or get explicit exception with documented rationale.
• Compliance evidence.: Most compliance frameworks require MFA for privileged access. The audit produces the evidence. SOC 2, HIPAA, PCI DSS all reference MFA requirements; the audit answers the relevant controls.

MFA enforcement is one of the highest-leverage security investments and one of the cheapest to deploy. Nova AI Ops integrates with IDP audit streams and cloud configuration auditing, surfaces MFA coverage gaps, and tracks the program's maturity trajectory over time.