--- title: secnostic platform canonical: https://www.secnostic.com/en/products/platform language: en dateModified: 2026-08-12 alternate-de: https://www.secnostic.com/de/products/platform --- # secnostic platform - URL: https://www.secnostic.com/en/products/platform - Positioning: SaaS governance and multi-tenant operations secnostic platform handles tenants, identities, roles, access, and onboarding in one place, so no app has to reinvent any of it. No app builds its own login, tenant separation, or permissions anymore. That makes running several applications easy to scale and easy to audit. **One foundation for every app** Every app needs login, tenants, roles, and access. When each one builds that alone, the effort multiplies and mistakes creep in. secnostic platform handles this foundation once for all of them: tenants with their own login, registered apps, permissions, and plans per customer. You onboard new customers in one place, control who sees what, and maintain a full overview even as the portfolio grows. **Capabilities** - Manage tenants, organizations, and onboarding flows centrally - Control identity providers, roles, permissions, and technical access - Register apps securely and provision their scope centrally - Keep changes, access, and governance decisions traceable **Outcomes** - Run multiple applications and customer areas without extra effort - Clean tenant separation and control over who sees what - An end to bespoke solutions for roles, apps, and onboarding **Modules of secnostic platform** - **Tenants** - Tenancy: Every subject and grant is scoped per tenant, cleanly separated, with no data mixing. - **Permissions** - Capabilities: The granular capabilities that can be granted within a tenant, each with a name and description. - **Grants** - Access (core module): The heart of it: assigns a permission or role to a person with Allow or Deny, bound to a tenant and with its own priority. Deny wins over Allow. - **Roles** - Bundles: Bundles permissions into a role that lists its permissions with effect, priority, and target. - **Authentication** - Sign-on: Configure OpenID Connect providers like Microsoft Entra for single sign-on. - **App Environments** - Environments: Apps register environments, and tenants get access to specific ones, such as production or test. - **Tokens** - Onboarding: Registration tokens are issued per team for onboarding. **From sign-in and app to governed access** secnostic platform is the shared control plane behind the secnostic apps. A request from inventory, focusAlert, or another app travels through the platform layer by layer: identity, tenant, access, entitlements, and finally the app itself. No app has to rebuild sign-in, tenant isolation, permissions, and plans. - **Identity**: OIDC and Microsoft Entra ID, per tenant - **Tenants**: isolated workspaces - **Access**: allow or deny, with priority - **Entitlements**: limits, plans, and quotas, per tenant or global - **Apps**: registered and connected **Access and tenancy in detail** Two mechanisms carry the platform: a grant resolver that decides every request, and the tenant separation that keeps everything within the context of exactly one tenant. _Access engine._ A role-based grant resolver decides what every user, app, and token may do. A sync engine ingests the permissions, entitlements, and metrics each app declares. Together they govern access and per-tenant configuration on every request. - **Permissions & roles**: Permissions are named actions per context; roles bundle them and carry a priority. - **Grants**: A grant assigns a role or permission, with an allow or deny effect, a priority, context, and optional expiry. - **Priority**: The highest-priority matching grant wins; deny beats allow at equal priority. - **Entitlement sync**: Apps declare entitlements and metrics; the platform validates and stores the values per tenant. Some entitlements are global and apply to the whole app rather than a single tenant. - **Token scope**: Tokens only inherit their owner's permissions and can never exceed them. The token an app ultimately receives carries only that app's permissions and the user information it needs. Access decisions and entitlement values are exposed over a REST API with a query syntax, so governance and provisioning can be automated. In practice: - **SaaS portfolio**: A software vendor onboards a new customer as an isolated tenant and enables two apps in the production environment. (Invite -> Tenant active -> App access -> Provisioning) - **Own sign-in**: A customer routes all sign-ins through its own Microsoft Entra ID instead of local accounts. (Provider -> Redirect -> User -> Session) - **Licensing & limits**: A product manager raises a customer's plan tier and reviews usage against the new limit. (Definition -> Set value -> App resolves -> Usage) **Isolated tenants with a clear lifecycle** Every customer is an isolated tenant with its own users, roles, permissions, sign-in providers, and entitlement values. Everything is evaluated only within that tenant's context. - **Isolated workspaces**: Users, roles, permissions, sign-in providers, app visibility, and entitlement values apply only within their tenant. A grant in tenant A never applies in tenant B. - **Onboarding and offboarding**: Operators send one-time, expiring invites. A tenant starts as a draft and becomes active. When an operator revokes access, it ends at once across the whole tenant, because every grant is bound to that tenant. - **Own sign-in per tenant**: Each tenant configures its own OAuth and OIDC providers, including Microsoft Entra ID. Users can belong to several tenants and switch context. - **App access per environment**: Access is granted per environment. A tenant may use the production environment of an app but not staging, toggled individually or as a bulk grant. **A look inside the platform** Permissions, roles, grants, and sign-in stay separate by task and share the same tenant model. - Permissions: the granular capabilities that can be granted within a tenant. - Create permission: define a new capability that roles and grants can reference. - Roles: bundle permissions, each with its effect, priority, and target. - Grant, step one: pick the right permission or role for a person. - Grant, step two: set the effect to allow or deny and bind it to the tenant. - Sign-in: configure OpenID Connect providers like Microsoft Entra for single sign-on. **FAQ** - Q: Do customers have to give up their existing logins? A: No. Each tenant configures its own OAuth and OIDC providers, with a preset for Microsoft Entra ID. Users authenticate through their own identity provider, and the platform then issues a session, acting as the relying party. - Q: How isolated is each tenant's data? A: A tenant is an isolated workspace. Users, roles, permissions, sign-in providers, and entitlement values apply only in its context. A permission for tenant A never applies in tenant B, so different customers' data and access never mix. - Q: Can customers tamper with their own limits? A: Only those the operator explicitly releases. Every entitlement is defined as global for the app or per tenant, and each can be visible, hidden, or tenant-configurable. The settings that control usage limits and billing are managed only by the operator; the platform stays the single source of truth, and apps query the current value at runtime instead of keeping their own editable copy. - Q: What does it take to add a new app? A: The app implements a documented integration protocol: a configuration file plus endpoints for info, status, OAuth, and its permission, entitlement, and metric definitions. On registration it receives a secret and OAuth credentials, after which the platform re-syncs the catalogs on a schedule. **Getting started.** We clarify which tenants, apps, roles, and entitlements should converge first and where the platform immediately cuts effort and one-off solutions.