MFA Renewal: Reconcile Every Protected App Before You Reprice Users

An MFA renewal can look clean and still leave important systems exposed.

The proposal says 1,200 users. Procurement confirms 1,200 employees. The vendor applies the new rate. Everybody moves on.

That is a seat count, not a security review.

Before you renew, reconcile the people, applications, access paths, policy scope, exceptions, authentication methods, and licenses. The decision is not whether your organization “has MFA.” The decision is whether the proposed service protects the identities and applications the business depends on, at the right level, without paying for coverage that exists only on paper.

Start with applications, not employees

Employee count is a useful commercial input. It is a bad proxy for MFA coverage.

One employee may access email, VPN, cloud administration, payroll, a finance platform, several SaaS applications, and a legacy line-of-business system. Some of those apps may use your main identity provider. Others may keep local accounts. A newly acquired business may have its own tenant. Contractors may sit outside the employee file. Privileged accounts may be licensed or counted differently.

Build the renewal inventory around access paths. For each application, record:

Business owner and technical owner
User populations, including employees, contractors, partners, and administrators
Identity source and sign-in method
Whether MFA is enabled, required, and successfully challenged
Authentication methods allowed
Policy exclusions and bypass conditions
Local, emergency, and vendor support accounts
Service accounts, workload identities, and integrations
License or service tier required
Evidence date and test result

If the provider cannot help you connect the proposal to that inventory, the proposal is not finished.

This is narrower than a full identity and access management review. You are trying to answer one renewal question: what does this agreement protect, and what does it leave outside the control?

Separate enabled, enrolled, enforced, and tested

These words are often treated like they mean the same thing. They do not.

Enabled means the feature is available in the tenant or application.

Enrolled means a user registered an authentication method.

Enforced means the applicable policy requires the user to complete MFA under defined conditions.

Tested means you have current evidence that the expected challenge happens on the real access path.

A dashboard full of enrolled users can look impressive while important groups, apps, protocols, or access conditions sit outside enforcement.

Google Workspace’s current 2-Step Verification deployment guidance tells administrators to track enrollment status, enforcement status, and security-key counts. It also documents policy scope by organizational unit or configuration group. That is a useful product example because it shows why the renewal evidence needs more than one number.

Ask the provider to show the denominator behind every coverage claim. If the report says 98 percent, 98 percent of what? Active employees? Licensed users? Interactive accounts? All accounts in one tenant? Applications using federation? Successful sign-ins during the last 30 days?

Without the denominator, the percentage is decoration.

Find the applications outside the main policy

The biggest renewal gap may not be inside the MFA platform. It may be the applications that never reach it.

Look for:

Apps with local usernames and passwords
Legacy protocols that do not support the current MFA flow
VPNs, firewalls, remote support tools, and administrative consoles using separate identity stores
Acquired companies or secondary tenants
Third-party portals with independent accounts
Shared, generic, kiosk, and service accounts
Old integrations that break when modern authentication is enforced
Emergency accounts intentionally excluded from normal policy
Recovery and help-desk processes that fall back to a weaker method

CISA’s phishing-resistant MFA guidance recommends identifying systems that do not support MFA and developing a plan to upgrade or migrate them. CISA also notes that enterprise identity and SSO integration can often add MFA to business applications.

That does not mean every old app can be fixed before renewal. It means the gap should have an owner, a treatment, a date, and a commercial consequence.

You might renew the platform and fund an integration. You might isolate an old application while a replacement is selected. You might accept a limited exception with added monitoring. You might decide that a supplier unable to cover a critical access path should not receive the full proposed commitment.

What you should not do is let an unknown gap quietly become another three-year dependency.

Reconcile the strength of the method

Coverage is not binary. A user can face an MFA challenge and still use a method that does not match the risk of the application.

NIST SP 800-63B Revision 4 says applications assessed at Authentication Assurance Level 2 must offer a phishing-resistant authentication option. A private mid-market company is not automatically required to apply federal assurance levels to every app. The framework is still useful: match authentication strength to the impact of the account and transaction.

Review the methods allowed for:

Privileged administration
Cloud control planes
Security, backup, and recovery systems
Finance and payment approval
Executive accounts
Remote access
Sensitive customer or regulated data
Account recovery and help-desk reset

Then check the fallback. A phishing-resistant method loses much of its value if the user can choose “try another way” and drop to a weak recovery path without meaningful control.

The broader MFA security guide explains the differences among SMS, push notifications, passkeys, and hardware security keys. At renewal, turn those technical differences into scope and price questions. Which methods are included in the proposed tier? Which require hardware, implementation services, device management, or another license? Which old methods remain available, and who can use them?

Treat exceptions as inventory

Every MFA program has edge cases. The problem is not the existence of an exception. The problem is an exception nobody can explain anymore.

For each excluded user, group, application, protocol, or condition, record:

Why the exception exists
Who approved it
What access it permits
What compensating control applies
When it was last used or reviewed
What event ends the exception
Who owns removal and retesting

Microsoft’s legacy authentication deployment guidance uses report-only mode before enforcement so administrators can see the effect of a policy. That is a sensible operating pattern for renewal corrections: observe current use, identify what would break, assign the repair, test it, and then enforce.

Do not confuse staged change with permanent exemption. If an exclusion has no owner or end condition, price and risk it as part of the current design.

Keep service identities out of the user-count argument

Service accounts and workload identities create two common mistakes.

First, buyers pay for user seats that do not solve the machine-access problem. Second, teams force a human MFA pattern onto an automated workflow and then create a bypass when it fails.

List nonhuman access separately. Identify how each workload authenticates, where its credential lives, how it rotates, which resources it can reach, and how use is monitored. Confirm whether the MFA supplier, identity provider, privileged-access platform, cloud platform, or application owner controls that path.

This matters commercially. A provider may correctly say that a service account does not consume a standard MFA seat while still selling another feature or tier needed to govern the workload. That may be a fair design. It needs to be visible in the proposal.

Build the renewal reconciliation

Put four records side by side:

Record	What it should prove
Agreement and proposal	Units, tiers, methods, support, implementation work, term, and pricing
Identity and application inventory	Every user population, account type, app, tenant, and access path in scope
Policy and exception export	Where MFA is enforced, what is excluded, and which methods are allowed
Sign-in and test evidence	What users actually encountered on representative production paths

Expect mismatches. The employee roster will not include every contractor. The license report may include inactive accounts. The policy may target a broad group but exclude one application. The application inventory may contain local admins nobody reviewed. The sign-in log may show a legacy path the architecture diagram forgot.

That is the work. Renewal leverage comes from finding those mismatches before the new term starts.

Put evidence and correction work into the deal

A lower seat price does not fix an uncovered application.

Before signing, define:

Final licensed populations and how quantities can change
Applications and tenants included in implementation or support
Required authentication methods by risk group
Exception cleanup and migration responsibilities
Reporting and export access
Test cases and pass criteria
Training, enrollment, and replacement-device support
Hardware or professional-service charges
Correction deadlines and retest requirements
Offboarding and configuration-export rights

If the provider is responsible for managed policy or implementation work, make the finish line measurable. If your internal team owns the gap, put the owner and date in the renewal record anyway. A contract cannot rescue work nobody accepted.

Choose one of four renewal outcomes

Renew at the proposed scope when application coverage, policy enforcement, methods, exceptions, support, and quantities reconcile with current evidence.

Resize the commercial scope when inactive users, duplicate identities, wrong tiers, or separate account populations make the proposal inaccurate.

Correct the design before committing when the platform fits but applications, exclusions, legacy paths, enrollment, recovery methods, or reporting need repair.

Compare another platform or service model when the current supplier cannot cover critical applications, cannot produce useful evidence, hides necessary controls in unclear tiers, or will not support a credible correction plan.

A gap does not automatically mean you should replace the vendor. It may be an application problem, an internal ownership problem, or a policy mistake. Find the layer that failed before you buy around it.

Renew verified coverage

Bring the agreement, proposal, user roster, contractor list, application inventory, policy exports, exception records, authentication-method report, sign-in logs, and sample access tests into one review.

Reconcile them. Test important paths. Price the corrections. Then decide.

If your MFA, identity, SSO, or managed security agreement is approaching renewal, request a Contract and Spend Risk Review. Catch Advisors can help you reconcile the commercial proposal with application coverage, user populations, exceptions, implementation work, and current evidence before you renew or compare options.