Partner program

Your customers' identity, from a single console

Anyone delivering managed services knows the problem: every customer brings their own directory, their own policies and their own auditor, and the cost of identity grows with the number of users that customer hires. The tenant model flips both — an isolated tenant per customer, and a price that does not depend on how many users are inside it.

Four things that change when you manage several customers

It is not a different price list on the same product: these are properties of the architecture that only show once you have more than one customer.

One tenant per customer, genuinely isolated

Each end customer gets its own tenant, with a dedicated cryptographic key pair, certificates and unique salts. Isolation is not an application rule to respect but a property of the cryptography: compromising one customer's tenant has no impact on the others you manage.

White-label login under the customer's brand

Each tenant presents its sign-in screen with its own logo, colors and domain, and with separately configured 2FA policy. The end customer sees their own brand, not yours and not the platform vendor's either.

Cost does not grow with your customers' users

Pricing is flat and based on tenants and projects, with unlimited users included. Signing a three-thousand-employee customer does not multiply platform cost: that is the difference between a margin that holds and one that thins out with every contract won.

No access to your customers' data

End users' personal data stays inside the customer tenant and the Cloud only operates on encrypted, pseudonymized data: neither you nor the platform vendor can read it. It is an argument that closes many conversations with the customer's DPO before they even start.

The detail of the cryptographic isolation is on the security page, and the per-tenant customization on white-label authentication.

Who works with this model

Four different profiles with the same underlying problem: governing identities that belong to different organizations.

Managed service provider

You run authentication as a recurring service for your customer portfolio: spin up a tenant per customer, configure SSO to Google Workspace or Microsoft Entra ID and enforce mandatory 2FA where the contract requires it, without maintaining separate identity infrastructure for each.

System integrator

You deliver application projects that must authenticate users from the first release. The multi-project model lets you connect several applications to the same tenant, each with its own cryptographic key and policies, without duplicating user records.

Software houses and ISVs

Your product is sold to multiple organizations and each wants its users separated from the others. Instead of building and maintaining a multi-tenant identity layer inside the application, you delegate it to the platform and stay on your functional domain.

Compliance and migration consulting

You guide customers through NIS2 alignment or a move away from a non-EU provider. Architectural alignment with GDPR, NIS2 and ISO 27001 and the three-phase migration path become part of your offering instead of a constraint to work around.

If your product is a SaaS sold to multiple organizations, the reference page is the identity layer for B2B SaaS. To move a customer off an existing provider, see IAM migration.

How you automate it

Onboarding a new customer should not have to go through a console. Tenant creation, user provisioning, linking applications to projects and revoking access are all driven from documented REST APIs, TypeScript and .NET SDKs and webhooks: the same route you use for the rest of your automation.

Native SCIM 2.0 support and SIEM integration are on the platform roadmap: today user synchronization is achieved via APIs and SDKs, and access events are available for audit and traceability.

Partner program FAQ

Each end customer maps to a separate tenant and each application to a project linked to that tenant. Cryptographic keys, certificates and salts are unique per tenant, so separation between your customers is structural and does not depend on configuration anyone could get wrong.

Not unless you want them to. White-label authentication lets each tenant present its own logo, colors, name and domain: linked projects automatically inherit the tenant branding. The end user interacts with a fully customized sign-in interface.

The model is flat, based on tenants and projects, with unlimited users included: there are no per-active-user fees. A customer going from one hundred to one thousand users does not change the platform cost line, which stays predictable as the portfolio expands. Specific partner commercial terms are agreed directly with the sales team.

Yes. Two-factor authentication is configured per project — disabled, optional or mandatory — and each tenant independently sets the enabled SSO providers, authorized email domains and session policies. Customers with different regulatory requirements coexist without settling for the lowest common denominator.

Through documented REST APIs, TypeScript and .NET SDKs and webhooks: tenant creation, user provisioning, project linking and access revocation can all be automated from your systems. Native SCIM 2.0 support is on the platform roadmap; today the same outcome is achieved via APIs and SDKs.

It starts with a conversation with the sales team to understand how many customers you manage, which regulatory requirements they bring, and how the platform fits into the service you already deliver. Scope and terms are defined from there.

Let's talk about your customer portfolio

How many customers you manage, which regulatory requirements they bring and how you deliver authentication today: those are the three questions the conversation starts from. Write to us mentioning you are a partner and the sales team will get back to you.