Single sign-on and access control.

Every business software tool asks the same question: who is this person? Historically, each tool answered it with its own password, and each password became a separate risk. Staff reused passwords, forgot them, and kept them on sticky notes. When someone left the company, access to each tool had to be removed one by one, and some were missed. Single sign-on solves this by letting a company manage identity in one place. People sign in once with their company account, and the tools they use trust that account. This article explains what single sign-on is, why it matters for customer data, how the standards work at a high level, how to set it up safely, how to test it without locking people out, and how to offboard someone properly.

What single sign-on is

Single sign-on separates identity from the application. An identity provider is the system that confirms who a person is. It holds the directory of staff, the passwords or other factors used to sign in, and the policies such as how often a password must change. An application, such as a CRM, trusts the identity provider to confirm identity, and it decides only what that person is allowed to do inside the application.

The most common standards behind single sign-on are OpenID Connect and SAML. Both let an identity provider send a signed statement about a user to an application. The application checks the signature, reads the statement, and creates a session. A user never gives the application their password, which means the application never stores it.

For a business, the practical result is one place to manage access. When a person joins, they are given access to the identity provider and then to the applications they need. When a person leaves, disabling their identity account removes access to every application that relies on it at the same moment.

Why it matters for customer data

Customer data is among the most valuable and most sensitive information a business holds. Contact details, contract values, and payment histories are all targets for attackers, and the weakest point is usually a password. Single sign-on reduces the number of passwords in circulation, and it lets the company enforce stronger rules across every tool in one step.

It also improves accountability. When each person signs in with a named company account, the activity in each application can be traced to that person. Shared logins and reused passwords make it impossible to know who made a change, which weakens both security and trust.

Finally, it reduces the risk of forgotten access. The most common access problem in business software is an account that stays active after its owner has left. Centralised identity makes that failure far less likely, because the disabled identity cuts off every connected tool at once.

Multi-factor sign-in

A password alone is a weak defence. Multi-factor authentication adds a second check, such as a code from an authenticator app, a hardware key, or a confirmation on a trusted device. Most identity providers can require it for every sign-in, and the company should do so for any application that holds customer data.

Apply the policy consistently. An application that allows sign-in without the second factor is the weakest link in the chain, and attackers look for it. Review the list of applications connected to the identity provider, and confirm that each one follows the same rules.

Plan for lost devices. Staff will lose phones and forget keys. Set a clear recovery process that verifies identity before resetting a second factor, and that does not rely on a single person. A recovery process that anyone can exploit is worse than no second factor at all.

Setting it up safely

Start with a clear inventory. List the applications that will use single sign-on, the people who will sign in through each one, and the roles they need. This list becomes the basis for testing and for the offboarding process.

Create a separate application registration for each tool in the identity provider. Each registration has its own client identifier and secret, and each one should be scoped to the minimum set of permissions. A shared secret across several tools is a single point of failure, and a secret that leaks should be easy to replace without affecting other tools.

Store secrets securely. A client secret should live in a password manager or a secrets vault, not in an email or a shared document. Rotate secrets on a schedule, and replace any secret that may have been exposed. Record the date of each change, so that the team knows when an old secret stopped working.

Testing without locking people out

Test every change from a second session. A common mistake is to change the sign-in settings while signed in with the same account, and then to discover that the change broke sign-in for everyone. Keep one administrator signed in with a separate, known working method, such as a password and a second factor, while the test runs in another window.

Test with a normal user account as well. An administrator account often has different permissions and different policies, so a test that succeeds for an administrator may fail for a standard member. Sign out completely between each test, and sign in again, so that the full path is checked and not just the session that was already open.

Keep a fallback. Document how to sign in without single sign-on if the identity provider is unavailable. This may be a local password for an owner, stored securely, and used only in an emergency. The fallback protects the business from an outage, but it must be guarded, because it is also an attractive target.

Offboarding

Offboarding is where single sign-on pays off. When a person leaves, disable their account in the identity provider on their last working day, or immediately if the departure is unexpected. Their sign-in to every connected application stops at once. Then remove the person’s role in each application, disconnect any personal accounts they connected, and reassign their records to a new owner.

Write the offboarding steps down, and assign a named person to carry them out. A checklist with a due time and a sign-off prevents the steps from being missed. A departure that is not recorded is a departure that someone will forget to complete.

Review the list of active accounts each quarter. Compare it with the current staff directory, and investigate any account that does not match. Contractors and temporary staff deserve the same care, with an end date set when their access is granted.

Summary

Single sign-on lets a company manage identity in one place, using standards such as OpenID Connect and SAML. It reduces the number of passwords, improves accountability, and makes offboarding reliable. Pair it with multi-factor sign-in, create a separate registration and secret for each tool, and store the secrets securely. Test every change from a second session, keep a guarded fallback, and follow a written offboarding checklist. A business that manages identity this way protects its customer data and makes access simpler for everyone who works in it.