MFA maturity is shifting from checklist controls to risk-based access

At a glance

What this is: This is a 1Kosmos analysis of Gartner's seven-track MFA maturity model, arguing that MFA needs to move beyond checklist deployment into risk-based governance, DevOps integration, credential hardening and session management.

Why it matters: IAM teams, PAM teams and identity architects need this because MFA fails to scale as a control unless it is managed as part of broader access governance across users, applications and sessions.

Context

MFA is a control, but it is not a complete access strategy. The article argues that mature programmes have to decide where stronger authentication is justified, how it is embedded into delivery pipelines, and how it is sustained after initial rollout.

For IAM practitioners, the shift is less about adding another factor and more about treating authentication as a governed capability. That means aligning MFA with risk, device and application context, then maintaining it through configuration, credential and session controls.

Key questions

Q: How should teams move from checklist MFA to risk-based access decisions?

A: Start by classifying applications, data and workflows by sensitivity, then map the level of authentication strength to each tier. The goal is not to add more factors everywhere, but to apply stronger verification where the business risk justifies it and lighter friction where it does not.

Q: Why do MFA programmes fail when DevOps teams are not involved?

A: Because implementation drift usually starts in delivery pipelines, configuration defaults and exception handling. If security requirements are not embedded into development and release processes, MFA can look complete on paper while still leaving bypass paths, inconsistent enforcement and fragile application integrations.

Q: What signs show that MFA is not mature enough for production risk?

A: Frequent exceptions, inconsistent enforcement across applications, weak credential hygiene and long-lived sessions all suggest the control is not being governed as part of the access lifecycle. Those are signs that MFA exists, but the surrounding identity controls are not keeping it effective.

Q: Should organisations treat credential controls and session management as part of MFA governance?

A: Yes. MFA only delivers durable assurance when credential quality and session lifespan are managed alongside the login control itself. Weak passwords, reused credentials and sessions that remain valid after risk changes all reduce the practical value of the authentication step.

Technical breakdown

Risk-based MFA strategy versus checklist deployment

Checklist MFA treats authentication as a binary requirement, usually applied uniformly after a policy decision. Risk-based MFA is different because the control strength changes with the asset, user, session or transaction context. That means the programme has to decide when step-up is warranted, when friction is acceptable and when other controls should carry more of the burden. In practice, MFA maturity is less about factor count and more about whether access decisions are proportional to risk.

Practical implication: classify access paths by risk and tune MFA strength accordingly instead of applying one default policy everywhere.

DevOps integration and MFA implementation drift

When MFA is introduced late, implementation often becomes inconsistent across applications, environments and release pipelines. The article's DevOps track points to a common failure mode: authentication controls that look sound in policy but degrade during deployment because teams lack integration guidance, templates or guardrails. MFA then becomes vulnerable to misconfiguration, bypass paths and exceptions that accumulate over time. Mature implementation depends on making MFA part of the application delivery lifecycle, not a separate security afterthought.

Practical implication: embed MFA requirements and test cases into application delivery workflows so control drift is detected before release.

Credential integrity and session management as MFA companions

MFA does not solve all authentication risk on its own. If passwords remain weak, credentials are reused, or sessions stay valid after trust changes, attackers can still work around the second factor. That is why the article pairs MFA with credential management and session management. Credential integrity reduces the chance that initial authentication is compromised, while session controls limit how long a valid login remains useful after context changes or abuse.

Practical implication: manage credential quality and session lifespan as part of the MFA programme, not as separate hygiene tasks.

NHI Mgmt Group analysis

MFA maturity is now a governance problem, not a feature problem. The article is really describing a shift from deploying authentication to governing trust decisions across the access lifecycle. Once MFA is treated as a binary rollout, teams miss the harder questions about risk tiering, implementation consistency and session durability. The implication is that IAM programmes need to measure MFA as a control system, not as a checkbox.

Risk-based MFA exposes where static policy breaks down. A uniform factor policy assumes that every access request deserves the same treatment, but that assumption does not hold across high-value assets, privileged workflows or sensitive sessions. Gartner's seven-track model, as presented by 1Kosmos, reinforces that authentication strength has to follow the asset and the context. Practitioners should therefore treat MFA exceptions as design decisions with governance consequences, not administrative conveniences.

Credential integrity remains the hidden dependency behind MFA effectiveness. MFA can only add resilience if the surrounding credential estate is controlled, because reused, weak or poorly managed credentials undermine the assurance the second factor is meant to provide. This is where authentication, credential lifecycle and session governance converge. Teams that isolate MFA from the rest of identity hygiene will keep finding gaps that are structural rather than procedural.

Session management is where MFA maturity either holds or decays. If access remains valid long after authentication context has changed, the second factor becomes less meaningful over the life of the session. That makes session control part of authentication governance, not a separate technical concern. The practical conclusion is that mature MFA programmes must govern post-login risk, not just login-time verification.

Track-based MFA thinking gives IAM teams a better operating model. The value of the seven-track framing is that it separates design, delivery, hardening and operational sustainment into distinct governance questions. That structure is useful because MFA failures rarely come from one control alone. They usually come from the interaction between policy, deployment, credentials and session handling, which is exactly where practitioners need to focus.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Risk-based MFA is a maturity model, not a point product requirement. IAM teams should read this as a signal to stop treating authentication strength as a universal setting. The operating question is which access paths deserve step-up, which can remain low-friction and which need separate compensating controls.

Credential integrity and session governance now sit inside the MFA control boundary. That matters because authentication cannot be judged only at login time. If access stays valid too long or if credentials remain weak or reused, the control loses force after the initial challenge.

Track-based planning is useful because MFA failure usually happens across handoffs. Security architects should align design decisions, DevOps implementation, credential hygiene and session policy rather than managing those as separate workstreams.

For practitioners

• Define risk tiers for MFA enforcement Map applications, assets and workflows to risk tiers so authentication strength is proportional to the sensitivity of the action being protected.
• Embed MFA requirements into DevOps workflows Add MFA configuration, testing and exception handling to release pipelines so implementation quality is verified before deployment.
• Harden credential controls around MFA Reduce weak, reused and stale credentials so the assurance provided by MFA is not undermined by poor credential hygiene.
• Review session duration and reauthentication triggers Set session controls so elevated trust does not persist after the risk context changes or a session becomes unusually long-lived.

Key takeaways

• MFA maturity is shifting from a deployment checklist to a governed access decision that changes with risk, application context and session state.
• The control only remains effective when credential quality, DevOps implementation and session duration are managed alongside the factor challenge itself.
• IAM teams should treat MFA as part of lifecycle governance, not as a standalone authentication toggle.

Key terms

• Risk-Based MFA: Risk-Based MFA is multi-factor authentication that changes its challenge level based on the situation. It evaluates signals such as device trust, location, behavior, network, and transaction sensitivity, then decides whether to allow access, step up authentication, or block the request. This reduces unnecessary friction while preserving stronger control when risk rises.
• Credential Integrity: The degree to which a secret, token, password, or certificate is still safe to trust for authentication. In practice, integrity depends on exposure status, reuse, rotation, and whether the credential can still be used by someone who should not have it.
• Session Management: Session management is the control layer that keeps track of an identity after successful authentication. Good session management limits how long access lasts, protects session material from theft, and supports fast revocation when risk changes. Poor session handling often turns one valid login into prolonged unauthorized access.
• Authentication Drift: Authentication drift is the gradual divergence between intended access policy and how users actually log in. It appears when teams enforce SSO or MFA in some places but not others, or when legacy accounts and local credentials remain in use. Drift matters because it creates hidden exceptions that attackers can exploit quietly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.