Challenge
Users keep access after SSO is turned on, through an old password or API key.
Agnotic approach
Enforcing SSO also revokes password sessions and asks admins to review existing API keys.
SaaS Enhancement
SaaS enhancement for enterprise readiness
Enterprise deals stall when the security review asks for single sign-on, automatic deprovisioning and audit logs your product does not have. Agnotic Technologies adds those features to your existing SaaS product, in the order buyers check them, without a rewrite.
SSO and SCIMRoles and permissionsAudit log exportNo rewrite
Trusted by global innovators
Enterprise readiness
What is SaaS enhancement for enterprise readiness?
SaaS enhancement is adding the features enterprise buyers require to a SaaS product that already has customers, without rebuilding it: single sign-on, SCIM user provisioning, custom roles, exportable audit logs, data retention and deletion, and an admin console. Agnotic Technologies builds these into your existing codebase in the order buyers check them.
These features rarely change what your product does. They change who controls access to it: the customer's IT team, through their own identity provider, policies and logs.
Tenant isolation and data residency are a separate design question, covered on our multi-tenant SaaS backend page. This page is about the features a buyer's security team asks for during procurement.
Enterprise feature checklist
Which enterprise features do buyers check, and in what order do we add them?
We use this checklist with your sales and engineering leads to plan the work. The build order follows what blocks deals most often in security reviews.
| Feature | Standard | What the buyer's security team checks | Build order |
|---|---|---|---|
| Single sign-on | SAML 2.0 and OpenID Connect | Users sign in only through our identity provider, and password login can be turned off for our domain | First |
| User provisioning and deprovisioning | SCIM 2.0 (RFC 7643 and RFC 7644) | Removing a person in our directory removes their access to your product without a support ticket | Second |
| Roles and permissions | Your own permission model | Our admins can create roles and limit who sees, edits and exports which records | Third |
| Audit log with export | NIST SP 800-92 log management guidance | Every sign-in, permission change and data export is logged with who, what, when and where, and we can stream it to our SIEM | Fourth |
| Data export, retention and deletion | The customer's contract and privacy terms | We can set how long data is kept, export all of it, and get confirmation when it is deleted | Fifth |
| Admin console | Product specific | Our IT team can manage domains, SSO settings, users, roles and logs without calling your support team | Built alongside each feature |
| Security questionnaire evidence | The buyer's own questionnaire | Answers backed by screenshots, settings, test reports and policies, not promises | Collected as each feature ships |
Most products we work on can add single sign-on and SCIM without touching the core data model. Roles and audit logs usually need more change, so we plan them with the data model in view.
What do we add to an existing SaaS product?
The modules behind most enterprise security reviews, built into your codebase and documented for your team.
Single sign-on
SAML 2.0 and OpenID Connect connections per customer, domain verification, just-in-time account creation and an option to enforce SSO for a domain.
SCIM provisioning
SCIM 2.0 /Users and /Groups endpoints, so the customer's identity provider creates, updates, deactivates and removes accounts and group memberships.
Roles and permissions
Custom roles built from fine-grained permissions, checked on the server for every request and every record, not only hidden in the interface.
Audit logs
An append-only log of sign-ins, permission changes, exports and admin actions, searchable in the product and streamed to the customer's SIEM.
Retention, export and deletion
Per-customer retention settings, full data export in documented formats, and deletion jobs that produce a record of what was removed.
Admin console
One place for the customer's IT team to manage SSO, provisioning, roles, sessions, API keys and logs.
No rewrite
How do we add enterprise features without a rewrite?
Enterprise features go into a live product with paying customers, so every change ships behind controls.
- Each feature ships behind a feature flag and is turned on per customer, starting with the account that asked for it
- Single sign-on runs alongside password login until the customer's admin enforces it for their domain
- Permission checks are added in a shared authorization layer, so existing screens keep working while roles are introduced
- Audit events are written by the same code path that performs the action, so the log cannot drift from what happened
- Database changes are additive first and cleaned up later, so a rollback never needs a data restore
- Every release adds tests for the new access rules before the flag is turned on for more customers
Failure points
Where do enterprise features break in an existing codebase?
Problems we find when we add enterprise features to a product that grew without them.
Challenge
A deprovisioned user still appears in reports and assignment lists.
Agnotic approach
SCIM deactivation sets a clear account state that every query respects, and deletion follows the customer's retention setting.
Challenge
Permissions are checked in the interface but not in the API.
Agnotic approach
Every API route and background job calls the same authorization check, with tests per role.
Challenge
Audit logs miss actions done by admins, support staff or scripts.
Agnotic approach
Support and system actions are logged with their own actor type, and support access to a customer account is logged and visible to that customer.
Challenge
Data export works for small accounts and times out for large ones.
Agnotic approach
Exports run as background jobs that write files in parts and notify the admin when ready.
Challenge
Each enterprise deal adds a custom one-off setting.
Agnotic approach
Settings live in the admin console as product features, so the next customer gets them without new code.
Who it is for
Which SaaS teams ask for this work?
Teams whose product works well, but not yet for the buyer's IT and security teams.
Startups closing their first enterprise deal
SaaS enhancement for startups usually starts with SSO and SCIM, because those two block procurement most often.
Product-led companies moving upmarket
Self-serve products adding the controls that larger accounts need before they roll out to every team.
Vertical SaaS selling to regulated buyers
Products for finance, healthcare or public sector buyers, where audit logs and retention rules are written into contracts.
Teams answering security questionnaires
Companies that keep answering "planned" to the same questionnaire rows and want working features and evidence instead.
Acquired products joining a larger platform
Products that need to plug into a parent company's identity provider, roles and logging.
Scope and cost
What drives the cost of SaaS enhancement?
Prices are not published. Your quote follows from how far the codebase is from each checklist item, which we assess on the scoping call.
Current authentication
Whether sign-in is already centralized or spread across apps, services and legacy session code.
Permission model
How far the product is from per-record permissions, and how many screens and API routes need checks.
Identity providers to support
Which providers your customers use for SSO and SCIM, and how many customer configurations need testing.
Audit and retention depth
Which events must be logged, where logs are streamed and which retention rules your contracts promise.
Architecture
A single application or several services, and whether background jobs and integrations also need access checks.
Evidence needs
How much documentation and test evidence your sales team needs for questionnaires.
Standards
Standards we build enterprise features to
The specifications behind the checklist above.
SAML 2.0OpenID ConnectSCIM 2.0NIST SP 800-92OWASP ASVS
Facts and sources
Facts behind enterprise SaaS features
Specifications that define how SSO, provisioning and logging work, each linked to its primary source.
OpenID Connect 1.0 is an identity layer on top of the OAuth 2.0 protocol, and its ID Token is a security token that carries claims about how the identity provider authenticated the user.
Source: OpenID Connect Core 1.0 (OpenID Foundation)SCIM 2.0 is an HTTP-based protocol for managing identities across domains, with standard /Users and /Groups endpoints that a customer's identity provider calls to retrieve, add and modify accounts.
Source: RFC 7644, SCIM Protocol (IETF)After a SCIM DELETE request, a service provider may keep the data but must return 404 (Not Found) for every operation on the deleted resource and leave it out of future query results.
Source: RFC 7644, section 3.6 (IETF)NIST SP 800-92, Guide to Computer Security Log Management (September 2006), gives guidance on developing, implementing and maintaining log management practices across an organization.
Source: NIST SP 800-92 (NIST CSRC)
Engagement
How does a SaaS enhancement engagement run?
From code review to rollout across your customer base.
1.
Scoping call and code review
We review your authentication, permissions and logging code against the checklist and agree which features the first release includes.
Scope2.
Fixed-scope first release
We build the first features behind flags, test them with the customer who asked, and write the questionnaire evidence as we go.
Build3.
Roll out and extend
We turn features on for more customers, add the next items on the checklist and hand the code to your team or keep supporting it.
ExtendFrequently Asked Questions
There is no fixed price list. Cost follows how sign-in and permissions work today, which identity providers you need to support, how many events must be audited and how many services are involved. You get a written proposal after the scoping call.
It depends on the features and the state of your codebase, so we agree a fixed first release on the scoping call. Single sign-on and SCIM are usually the first release because they unblock the most deals.
Usually both. Many large companies still configure enterprise apps with SAML 2.0, while newer identity setups often prefer OpenID Connect. We build one SSO layer that supports both, so each customer can use what their IT team runs.
Yes. We add them in layers around your existing code: a shared authorization check, an audit event writer and identity endpoints, each behind a feature flag. A rewrite is only worth discussing when the current code cannot be tested at all.
Yes. We test SSO and SCIM against the providers your customers use, such as Okta, Microsoft Entra ID and Google Workspace, and write setup guides your customers' admins can follow without your support team.
Only when enterprise deals are in front of you. If a prospect's security review lists SSO or SCIM as required, adding them is usually cheaper than losing the deal. Otherwise we keep the design ready and build later.
Engineers may use AI coding assistants for routine code, but access control and audit code is written and reviewed by an engineer line by line, with tests for every role. Nothing reaches your main branch without code review.