SaaS SSO Renewal: Find Every Paid App That Still Bypasses the Identity Provider

A SaaS application can appear in your identity provider and still let users walk around it.

The SSO tile works. The vendor says the application supports SAML. IT sees assignments in the directory. Procurement sees paid seats on the renewal quote.

Okay, but can a former employee still sign in with a local password? Does the app have shared accounts? Are administrators using a separate login path? Does disabling the identity account remove access, or only remove the tile?

Before you renew a material SaaS agreement, match every paid application to its real authentication paths, identity assignments, local accounts, provisioning method, sign-in evidence, and offboarding result. Then decide what to keep, correct, retire, restrict, or compare.

Start with the paid application list

Your identity provider is an important source. It is not the complete SaaS inventory.

An application appears there only if someone added, discovered, or integrated it. Finance may be paying for other software through invoices, expense reports, cloud marketplaces, or department cards. Some users may have created accounts before SSO was deployed.

Start with the commercial record. Pull the agreement, renewal proposal, invoices, accounts payable records, expense data, software inventory, and business-owner list. Match that list against the applications and assignments in your identity provider.

NIST Cybersecurity Framework 2.0 gives this work two useful anchors. It calls for inventories of software, services, and systems. It also says identities and credentials should be managed, while access permissions, entitlements, and authorizations should be defined, enforced, and reviewed.

NIST does not require every application to use one SSO platform. A renewal decision still should not depend on an application list or access model nobody has reconciled.

Create one row per application tenant or workspace. If two departments use separate instances of the same product, keep them separate until you prove the access, data, owners, and contracts are the same.

Field	What to capture
Commercial record	Vendor, product, tenant, agreement, renewal date, notice date, units, tier, and cost
Ownership	Business owner, technical owner, application admin, budget owner, and renewal approver
Identity path	Identity provider, SSO protocol, assigned groups, direct login URL, and enforcement setting
Other access	Local users, shared accounts, guests, administrators, support users, service accounts, and API access
Provisioning	Manual, directory group, SCIM, HR-driven, just-in-time, or another method
Evidence	Assignment export, application user export, sign-in logs, license report, and test date
Decision	Keep, correct, retire, restrict, compare, or investigate

The broader SaaS sprawl audit can help you discover applications and duplicate tools. This renewal review goes one layer deeper. It asks whether the identity control and the paid application population describe the same users.

Do not confuse SSO support with SSO enforcement

“Supports SSO” is a product capability. It is not proof that your tenant uses it correctly.

Separate these states:

Available: The vendor offers an SSO feature for the product and edition.
Configured: Your tenant has a federation connection to an identity provider.
Assigned: Current users or groups have access through that connection.
Enforced: Applicable users cannot fall back to an unapproved sign-in method.
Provisioned: Accounts are created, updated, and disabled through a controlled process.
Tested: Current evidence shows the expected path works for joining, changing roles, and leaving.

Microsoft’s current Entra application-management documentation separates these jobs. It describes SSO, resource assignment, access and consent, automated provisioning, permissions, Conditional Access, reporting, monitoring, and eventual cleanup as different parts of managing an application. That is a useful reminder for any platform: adding an app to the directory does not finish the access lifecycle.

Ask the SaaS vendor which product, edition, tenant, and user population the proposed SSO capability covers. Confirm whether SSO, automated provisioning, group mapping, audit logs, or multiple identity providers require different tiers. Use current documentation and your tenant settings. Do not let a sales slide answer a configuration question.

Find every route around the identity provider

A clean SSO test proves one path. Your audit needs to find the others.

Review the application directly, not only the identity console. Export users, roles, authentication methods, connected identity providers, API credentials, integrations, and recent access where the platform allows it.

Look for:

Local usernames and passwords created before SSO
Email-and-password login still available after federation
Shared or generic accounts
Application administrators exempt from normal SSO
Guests and external collaborators using another identity source
Contractor accounts outside the employee directory
Vendor support access
Mobile, desktop, or legacy clients with a separate login flow
Service accounts, API tokens, OAuth grants, and integration users
Secondary tenants or workspaces owned by another department
Accounts tied to personal email addresses

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

For renewal purposes, turn that guidance into an exception register. Every path outside the approved identity control needs an owner, business reason, authentication method, privilege level, last-use evidence, review date, and treatment.

Some exceptions are legitimate. An application may require an independent emergency administrator. A workload may need a nonhuman credential. The point is to stop renewing exceptions nobody can explain.

Reconcile five records

Put these records side by side:

The agreement, proposal, invoice, and license report
The identity provider’s application and assignment exports
The SaaS application’s users, roles, and authentication settings
Sign-in or activity evidence from both systems
The HR roster, contractor list, and current business-owner approval

Expect them to disagree.

The renewal may include 600 seats. The identity provider may show 540 assigned users. The application may contain 575 accounts, including local users and guests. Sign-in records may show only 410 active people during the period you reviewed. HR may identify former employees, role changes, or contractors that none of the other records explain.

Do not jump from that mismatch to an immediate license cut. Each record measures something different. A seasonal user may be valid without recent activity. An integration account may not look like a person. The contract metric may not equal the login count.

Investigate each difference and document what it means commercially and operationally.

Microsoft Entra’s current sign-in documentation shows why one report is rarely enough. It separates interactive user, non-interactive user, service principal, and managed identity sign-ins. Your identity platform and SaaS supplier may use different categories, retention periods, and report definitions. Record the denominator, date range, filters, and known blind spots behind every count.

Test the offboarding chain

The fastest way to find an SSO gap is to remove access from a controlled test identity and watch what happens.

Use a nonproduction or approved test account. Do not experiment with a real employee’s access without a change plan.

Run a practical sequence:

Assign the test user through the normal process.
Confirm the account and correct role appear in the SaaS application.
Sign in through the approved SSO path.
Check whether direct local login also works.
Remove the directory assignment or trigger the approved offboarding event.
Confirm what happens to the SaaS account, active sessions, tokens, mobile clients, shared content, and owned workflows.
Confirm the license becomes recoverable when the contract and product design say it should.
Review logs in both systems and retain the result.

Microsoft’s provisioning documentation describes automated creation, deprovisioning, synchronization, account discovery, and access governance as separate capabilities. It specifically includes discovering existing local or orphan accounts. That matters because a successful directory disable does not prove an old local identity disappeared.

If offboarding requires a manual ticket, test that process too. Measure who receives it, what evidence comes back, and what happens when the application owner is unavailable.

The goal is not a perfect demo. It is proof that the process you pay for works in the environment you operate.

Put correction work into the renewal

A lower per-user rate does not fix an application that bypasses the identity provider.

Before signing, define the work required to close known gaps:

Applications and tenants that must move under SSO
User populations and exceptions in scope
Local-account cleanup and emergency-access treatment
Group, role, and entitlement mapping
Provisioning and deprovisioning method
Required logs, exports, and retention
Test cases and pass criteria
Supplier, implementation partner, internal IT, security, HR, and business-owner responsibilities
Correction deadlines and retest dates
Pricing changes if the required control needs another edition or service
Export and transition obligations if you later leave

If the vendor cannot deliver SSO or lifecycle controls before the term begins, make a deliberate choice. You may accept the gap for a limited period, add another control, reduce the commitment, fund an integration, replace the application, or escalate the risk. Silence is also a choice, just a bad one.

Use the IT contract renewal calendar to start early enough for testing and correction. Identity work discovered inside the notice window is much harder to turn into commercial leverage.

Make an application-level decision

Keep the application and proposed scope when the business need, paid population, SSO enforcement, lifecycle process, exceptions, and evidence reconcile.

Correct when the product still fits but assignments, local accounts, roles, provisioning, logs, ownership, or license quantities are wrong.

Retire when the business no longer needs the application, another approved platform replaces it, or nobody will own the access and data cleanup.

Restrict when a valid exception needs narrower access, stronger authentication, monitoring, a shorter review cycle, or a defined end date.

Compare when the supplier cannot support the identity controls the risk requires, hides necessary controls in a poor commercial model, or will not support a credible migration and test plan.

Investigate when the contract, identity provider, application, activity data, and owner statements do not agree.

Do not turn SSO into a checkbox on the vendor scorecard. Use renewal to prove which people and machines can enter the application, how access changes, how it ends, and what you are paying for.

If a SaaS, identity, or managed access agreement is approaching renewal, request a Contract and Spend Risk Review. Bring the agreement, proposal, invoices, application inventory, identity assignments, SaaS user export, sign-in evidence, HR roster, exception list, and offboarding test. Catch Advisors will help you decide what to keep, correct, retire, restrict, compare, or investigate before you sign.