SSO Does Not Show Every Account: Access Inventory Blind Spots to Review Manually

SSO makes access easier to manage, but it does not prove every account exists inside your identity provider. You still need to review manual accounts, local admin users, vendor portals, shared/service accounts, contractors, legacy systems, and SaaS tools that were bought before SSO was enforced. Treat SSO as a strong control plane, not as a complete access inventory.

This article gives lean IT teams a practical checklist for finding the accounts that sit outside SSO and deciding how to review them. CertPilot’s role is manual-first evidence: records, owners, review decisions, and reports. It does not discover shadow SaaS or sync your directory today.

Why SSO is not the whole access picture

Single sign-on helps because it centralizes authentication for systems that support it and are configured correctly. It can reduce password sprawl, simplify offboarding, and make access review easier for connected apps.

The mistake is assuming “uses SSO” means “all access is visible.” In real companies, access grows through exceptions:

• a vendor portal that never supported SAML;
• a finance app with local emergency admin accounts;
• a founder-created SaaS subscription using a personal email;
• a contractor account created outside the normal joiner process;
• a shared mailbox or shared admin login;
• a service account tied to an integration;
• a retired system that still has active users;
• a department tool paid by card before IT knew about it.

Those accounts may not appear in an IdP export. If they are not in the export, they will not be reviewed unless you maintain another record of them.

The access inventory blind spots to check

Use this list before your next access review.

1. SaaS tools not connected to SSO

Many companies have a mix of SSO-connected and local-login SaaS. Start with the tools that store customer, finance, HR, support, or admin data. For each one, record:

• app name;
• login method;
• account export method;
• business owner;
• technical owner;
• whether users can self-invite;
• whether admin roles exist outside SSO.

If the app does not support SSO, it is not automatically bad. It just needs a manual review routine.

2. Local admin and break-glass accounts

Some local admin or emergency accounts are intentional. The danger is when nobody knows who owns them or when they were last tested. Record:

• account name;
• purpose;
• owner;
• where access is stored;
• who can use it;
• last reviewed date;
• evidence note.

Do not store passwords or recovery secrets in the access register. Store ownership and review evidence only.

3. Shared and service accounts

Shared and service accounts often fall through identity reports because they do not map to one employee. Treat them as owned objects:

• what system uses the account;
• what the account does;
• who owns it;
• whether interactive login is allowed;
• whether access is still required;
• when it should be reviewed again.

A shared account with no owner should be action required until someone accepts responsibility for it.

4. Contractors, vendors, and guest accounts

Contractor and vendor access is often temporary in theory and permanent in practice. Review:

• contractor end dates;
• vendor contract end dates;
• guest accounts in collaboration tools;
• portal accounts for agencies, consultants, and external admins;
• accounts created for project work that is now complete.

For vendor-related handoffs, use Vendor Access and Contract End Dates: Why Renewals Must Hand Off to Access Reviews.

5. Personal-email and legacy sign-ups

Early-stage companies often started tools before a formal domain, HR process, or SSO policy existed. Look for:

• accounts using personal Gmail/Outlook addresses;
• old founder or agency emails;
• aliases no longer monitored;
• apps paid by a card outside the normal procurement path;
• systems where the original buyer left.

This is where a People & Accounts register and a renewals/vendor register should cross-check each other. The payment owner is not always the access owner, but the payment record may reveal a system that needs review.

6. Systems marked retired but still reachable

Retired systems are easy to ignore because they are no longer in daily use. They can still hold accounts, exports, customer data, backups, or admin portals. Record whether the system is:

• active;
• retiring;
• retired but retained;
• archived;
• fully removed.

Then decide whether it should appear in access reviews. CertPilot’s Systems Catalog supports lifecycle status and a “use in access reviews” flag for exactly this reason.

How to build the manual evidence layer

Do not try to solve every blind spot with a giant one-time spreadsheet. Build a small evidence layer:

1. List known systems. Start with critical systems and vendor portals.
2. Mark login method. SSO, local account, shared account, service account, or unknown.
3. Record owners. Assign business and technical owners.
4. Attach people/accounts. Record known account identifiers and person status.
5. Flag unknowns. Unknown login method or owner is an action item, not a blank.
6. Review by system. Ask the system owner whether each listed access path is still needed.
7. Complete the review. Capture dated evidence and export the artifact.

That workflow is the same foundation as building a user-system access matrix without an IAM connector.

What not to claim from SSO data

Be careful with language when reporting up to leadership:

• Do not say “all accounts are controlled by SSO” unless you have verified all systems and exceptions.
• Do not say “offboarding is complete” just because the identity account was disabled.
• Do not say “no local accounts exist” unless each system owner confirmed it.
• Do not say “no access risk” when you only reviewed connected apps.
• Do not say “compliant” or “certified” from an access inventory alone.

Safer wording:

“SSO-connected systems are centrally managed. We also maintain a manual access register for local accounts, vendor portals, shared/service accounts, and known exceptions. The latest access review covered the systems listed in the report and recorded open action items separately.”

That answer is less flashy and more credible.

How CertPilot fits

CertPilot does not connect to Google Workspace, Microsoft 365, Entra, HR systems, finance systems, or SaaS APIs today. It does not discover shadow SaaS, scan OAuth grants, read invoices, or pull identity metadata.

What it can do is help you maintain the manual evidence layer around the systems you know about:

• People & Accounts for customer-entered people and account records;
• Access Reviews for access levels, review decisions, action-required notes, due dates, and completion evidence;
• Systems Catalog for systems, owners, criticality, lifecycle status, and review inclusion;
• CSV import/export for starting from existing spreadsheets;
• Access Review Register PDF and sample reports for management-ready artifacts.

That makes CertPilot useful beside SSO: the IdP handles supported systems; the register records review evidence for the messy edge cases SSO does not fully cover.

Manual blind-spot review checklist

Before signing off an access review, check:

• Are all critical systems listed in the Systems Catalog?
• Does each system have an owner?
• Do you know which systems are SSO-connected and which are not?
• Are local admin accounts recorded?
• Are shared and service accounts assigned to owners?
• Are contractor, vendor, and guest accounts reviewed?
• Are retired systems either removed from scope with a note or reviewed if still reachable?
• Are personal-email or legacy sign-ups investigated?
• Are action-required rows recorded instead of hidden?
• Is the completion note clear about scope and limitations?

If the answer is “no” to several, do not delay the review forever. Complete the current scope honestly and make the unknowns action-required for the next cycle.

In short

• SSO is valuable, but it does not automatically prove every account is known or reviewed.
• Manual blind spots include local SaaS accounts, vendor portals, service accounts, shared accounts, contractors, personal-email sign-ups, and retired systems.
• Build a manual evidence layer around known systems: owners, login method, account identifiers, review result, action required, and completion record.
• Report SSO scope honestly. Connected systems and manual exceptions are different evidence categories.
• CertPilot records the manual register and access-review evidence; it does not discover accounts, sync directories, or remove access.

Frequently Asked Questions

Does SSO show every account a company has?

No. SSO shows accounts for systems connected to that identity provider and configured to use it. Local accounts, vendor portals, service accounts, shared accounts, and legacy sign-ups may sit outside the SSO view.

How do I find accounts outside SSO?

Start with known systems, vendor and renewal records, owner interviews, admin exports, support tickets, offboarding checklists, and existing spreadsheets. Record what you find in a manual register and mark unknowns as action-required.

Should every app be forced into SSO?

SSO is usually preferable where practical, but some tools may not support it or may require local break-glass access. The evidence task is to record those exceptions and review them regularly.

Does CertPilot discover shadow SaaS accounts?

No. CertPilot does not scan finance records, browser activity, OAuth grants, inboxes, or directories. It is a customer-maintained evidence register and access review workflow.

What should management see about SSO blind spots?

Show the systems covered by SSO, the systems reviewed manually, the owner for each, the latest review date, and the open action-required items. Do not imply total coverage unless the evidence actually supports it.