Enterprise software development: SSO, roles and audit logs first

In enterprise software development, single sign-on, role-based access and audit logs are architecture decisions. They are not features to add once a big customer asks for them. If you decide how identity, permissions and audit trails work before the first feature ships, you pass security reviews with configuration. If you leave them for later, the first serious security questionnaire usually means a rewrite.

You may know the moment. A large prospect loves the demo. Then their IT team sends a security review asking about SAML, SCIM provisioning, least-privilege roles and tamper-evident logs. Your product signs people in with email and password, keeps an admin flag on the user table and logs nothing a security team would accept. The deal stalls while your team works out how deep the changes go.

Why can't you bolt SSO and permissions on later?

These three decide the shape of your data model, not just your screens. Every query, API route and background job depends on who the user is, which organisation they belong to and what they are allowed to do. Change those answers late and you touch everything.

Take SSO. With enterprise SSO, the customer's identity provider owns the user: Okta, Microsoft Entra ID or Google Workspace. Users can be created before they ever log in, through SCIM provisioning, and the customer can remove them at any time. If your app assumes people sign up themselves and own their records, removing a user leaves orphaned data and sessions that keep working.

Permissions have the same problem. When checks like if user.role == 'admin' are scattered across controllers, every new role means hunting through hundreds of files. Then a customer asks for a read-only auditor role, and your team cannot promise nothing was missed.

Audit logs are the hardest of the three to fix later.

You cannot backfill an audit log. If the product never recorded who changed a record and when, that history is gone, and no migration brings it back.

What does it cost to get this wrong?

The obvious cost is stalled or lost enterprise deals while the team rebuilds core tables. The less obvious cost is risk. A rewrite of identity and permissions touches every feature at once, so regressions slip into parts of the product nobody meant to change.

There are security consequences too. Former employees of a customer can keep access because removing them in Okta never ended their session. Support staff can see data they should not see. After an incident, nobody can answer the first question a customer's security lead asks: who did this, and when?

Then there is the roadmap. A quarter spent on plumbing is a quarter of features you did not ship, and your competitors notice.

Who does not need to design all of this up front?

If you are building an internal tool for one company, with a few dozen users on a single Google Workspace, you do not need SCIM, custom roles or SIEM export. The same goes for testing a consumer idea. Use a managed auth provider, keep a simple role column and move on.

One cheap habit is still worth it. Put an organisation ID on every record from day one if there is any chance you will sell to businesses. It costs almost nothing now and saves a painful data migration later.

What should a CTO require before enterprise software development starts?

Ask the team to design these seven things before the first feature. Each one has a reason a security reviewer will eventually test.

1. The organisation owns the data, not the user. Records belong to an organisation, and users belong to organisations through a membership that carries their role. Reason: when a customer removes an employee, the work they created has to stay with the company.

2. Identity is separate from the account. One user record can link to several sign-in methods, such as a password, Google or a SAML connection set up per organisation. Reason: one customer will enforce SSO for their own domain while their outside contractors still sign in with email.

3. SSO follows the standards. Support SAML 2.0 and OIDC, verify each customer's domain, and give their admin a switch that makes SSO mandatory. Reason: security reviews ask for both protocols by name.

4. Provisioning and removal are planned from the start. Support SCIM, and make sure removing a user ends their active sessions and API tokens within minutes. Reason: delayed removal is one of the first things reviewers check.

5. Permissions live in data, not in scattered code. Roles map to specific permissions like invoice:approve, and one policy function makes every check. Reason: custom roles become a settings change, not a code release.

6. The audit log is append-only. Each entry records the actor, action, target, organisation, time, IP address and the before and after values. Write it in the same database transaction as the change itself, let customers export it to their SIEM, and set a retention period. Reason: if a log can be edited or can miss events, nobody will trust it.

7. Support access is logged and visible to the customer. If your staff can impersonate a user to debug a problem, that session needs the customer's consent and its own audit entries. Reason: enterprise buyers will ask exactly who on your side can see their data.

Should you build identity yourself or buy it?

For most products, buy the SSO and SCIM layer and build your own permission model on top. Identity protocols are full of edge cases. Your permission rules, though, are your business logic, and they belong in your code.

Some rules to decide with:

• If your first enterprise customer is likely within a year, use a managed provider such as WorkOS, Auth0 or Clerk for SSO and SCIM.

• If contracts require data residency or on-premise deployment, self-host something like Keycloak and budget the time to run it properly.

• If access depends on relationships, like 'can edit documents in projects they own', look at relationship-based tools such as OpenFGA instead of growing an ever-longer role list.

• Whatever you choose, put it behind your own internal interface so you can swap providers without touching every feature.

What should you ask your team or vendor?

These five questions show quickly whether the foundation is sound:

• Show me where the permission check happens for this endpoint. Is it in one place?

• What happens to an active session when a customer removes a user in their identity provider?

• Can a customer admin see who exported data last Tuesday?

• Can our own staff read customer data, and is every instance logged?

• How do we add a new role without a code release?

If the answer to any of these is 'we would have to add that', you have a data model problem, not a missing feature. It is far cheaper to find that out now than in the middle of a security review.

If your product runs on Next.js, the Next.js enterprise guide shows how middleware, server components and API routes fit around these decisions.

Geminate Solutions has shipped 50+ products, including an EdTech platform with 250K+ daily active users. Clients own 100% of the code and IP.

Read the guide above, or send your current data model or architecture plan to Geminate Solutions for a free review. We sign an NDA before we talk and reply within 24 hours.