What questions should identity and access software have to answer?

Before a small business buys identity and access software, it should get written answers to five questions. Each one is explained below, with what to ask the provider and how to test the answer.

Score each provider answer as demonstrated, claimed, or not offered. Only demonstrated answers count toward the decision.

Terms you will meet in quotes

Single sign-on (SSO) lets one sign-in open many applications. SAML and OpenID Connect (OIDC) are the protocols that connect an application to the identity provider. SCIM creates and removes accounts in connected applications automatically, which is what makes leaving staff quick to close out. Multi-factor authentication (MFA) adds a second proof. FIDO2 and passkeys resist phishing because they work only on the real site.

Ask for an independent assurance report, such as a SOC 2 Type II report or an ISO/IEC 27001 certificate. Some applications also charge for a higher tier to unlock SSO or SCIM, so ask each application vendor, not only the identity provider.

For orientation, a business on Microsoft 365 already has Microsoft Entra ID, one on Google Workspace has Google's own sign-in controls, and dedicated providers include Okta and JumpCloud. Password managers such as 1Password and Bitwarden suit teams that need shared vaults more than central control. These are examples, not a ranking.

Question 1: Which applications does it cover?

The most costly mistake is buying central identity software before identifying applications it cannot govern. A polished sign-in for the main services can conceal important systems that remain outside the product, leaving staff to handle access manually. Begin with the boundary, rather than assuming a broad feature list proves coverage.

Ask the provider to check your actual application list, identify services outside central sign-in, and say what staff must still do. Then compare that remaining work with the administration the product removes. A shared vault can support separate systems, but it does not place those systems under central control.

Record the uncovered applications and the manual tasks they require before deciding whether central control is worth the operating effort.

Question 2: Is stronger sign-in required, not optional?

When stronger authentication and recovery are optional, an easier sign-in route can undercut the rest of the purchase. Make these controls acceptance requirements: phishing-resistant authentication such as passkeys or hardware security keys, visibility into factors registered to each account, and an administrator-visible recovery route.

Set the requirements before a trial. Ask whether MFA options go beyond codes and push approvals, and whether registered factors are visible. NIST's Digital Identity Guidelines, SP 800-63, and its authentication and lifecycle management guidance give context for those criteria. Require evidence for the sensitive applications your business actually uses.

Also ask which non-human identities the product can show, including service accounts, integrations, keys, and guest accounts. If a category is invisible, record that limit instead of treating an incomplete view as reassurance. The identity and access features page covers features that remove a decision rather than just inform one.

Question 3: How do we get back in when the provider is down?

A provider outage can lock staff out across the business, including from tools needed to restore access.

Ask what remains available during downtime, how an administrator can sign in, and where outage notices appear if company email uses the same sign-in route. Without a separate path, recovery may depend on the service that has failed.

Keep an emergency administrator account outside the normal provider route. Protect it with a hardware key or a strong passphrase stored physically, test it, and print recovery codes for accounts you cannot lose. Keep domain registrar and bank access on a separate path, and store outage instructions somewhere reachable without company email.

Use this short check to make the recovery route testable before purchase:

Write down who can use each fallback and where its instructions are kept. A recovery route nobody can find during an outage is not useful. The wider incident response plan can support the response, but the independent sign-in route still needs its own test.

Question 4: What evidence does it keep?

A current console view may not answer questions about what was visible or changed earlier. Ask what historical records the product retains, such as sign-ins, administrator changes and factor registrations, and whether they provide the detail your process requires.

Get the retention period in writing, and ask whether logs can be exported. NIST's log management guidance, SP 800-92, offers a reference for what to record, but the retention you need depends on your own contracts and insurance.

For fuller treatment of inventories, lifecycle changes, sessions, and account records, read identity and access. Ask the provider to demonstrate the specific record you need, rather than inferring its existence from a dashboard.

Question 5: Did it pass a trial, not just a demonstration?

A polished demonstration cannot establish that sign-in policies and recovery work with your applications and devices.

During a trial, have staff use the proposed authentication method on a sensitive service, then test the recovery route they would need if that method were unavailable. The test should reflect your actual requirements, not a prepared presentation.

Check whether the product supports the authentication choices you require, whether account factors are visible, and whether an administrator can complete recovery. Record what was tested and what remains uncertain.

Keep the trial focused on real requirements. Do not infer that the product meets them because its interface looks complete. Ask for the price per user per month, any minimum number of users, which features sit in higher tiers, and the contract term, and get the current quote in writing, since prices change. The same buying discipline applies across the security foundations software guide.

What it will not do: stop phishing

Buying identity software does not itself prevent phishing. Its contribution is indirect, through controls such as stronger authentication and shorter sessions on sensitive services. Ask which controls the product can enforce, where they apply, and whether staff can demonstrate the settings on the applications they actually use.

Identity controls are one layer among several; see the phishing defense comparison for the others. Check that the chosen product can require the authentication method you want on relevant applications. Do not assume every connected service inherits the same protection simply because it uses central sign-in.

Is central control worth the cost?

SSO may be worthwhile when the application count makes joining and leaving costly, or when nobody can answer access questions from memory. If those conditions do not apply, individual accounts, a password manager, shared vaults, and strong authentication may deliver much of the value with less operational effort.

Compare the administration the product removes with the tasks it leaves to staff, including uncovered applications and outage recovery. The identity and access comparison sets local accounts, a password manager and SSO side by side; use your actual workload to decide. A longer feature list is not evidence that the product reduces more work.