LoginMaster gives security leaders concrete, verifiable governance controls: roles and RBAC, server-side session revocation, anti-abuse defenses, granular account deletion and credential encryption. Here you'll find what ships today — no inflated claims — and, with the same clarity, what is on the roadmap.
Every control described here is part of the product today. Where a control has limits, we say so.
Six application roles — admin, admin_tenant, manager, user, technician, api_user — define what each account can do. The admin governs project membership and permissions: access to a project requires admin confirmation, not self-assignment. Privilege is explicit, granted and revocable.
No administrator can read or set a user's password, email or second factor: a direct defense against insider threat and privileged-account compromise. Access recovery goes through a recovery code held by the user plus an admin-approved request — never through an admin shortcut.
How access recovery works →Logout and revocation are enforced server-side via token blacklisting: a revoked session truly stops being valid, not only in the user's browser. Session duration is configurable by policy. At offboarding, project access, API keys and active sessions are revoked together.
Brute-force lockout blocks accounts after a threshold of failed attempts within a time window. Password reset is hardened against enumeration, so it does not reveal which addresses exist. SSO login URLs are signed, short-lived and origin-checked, preventing reuse or forwarding.
TOTP-based MFA, configurable per project with a disabled, optional or mandatory policy and an enrolment grace period; those who stay non-compliant can be deactivated. Adaptive MFA applies the second factor by role, project and context, together with conditional-access controls: authorized email domains, enabled SSO providers, session duration and lockout thresholds.
Explore adaptive MFA →Account deletion is granular: Full removes the user from the tenant and all projects, Local removes them from a single project while leaving the others intact. Two distinct levels to answer GDPR Article 17 precisely, without blanket deletions.
Credentials are protected with Argon2id and split-salt. Tokens carry a dual RS256 signature (Tenant + Cloud). The Tenant-Cloud architecture is zero-knowledge: the provider's cloud cannot read your users' credentials.
Security architecture details →
Transparency is a security control. Here is what you can use right now and what is in development: we don't sell today what isn't ready.
Note: application-level logging of authentication and access events is available today. A structured audit trail browsable from the UI and native SIEM export are on the roadmap, not yet available.
LoginMaster supports GDPR and NIS2 by design and is aligned with ISO 27001 controls. The Tenant-Cloud architecture keeps data in the customer's EU tenant, and the user's exclusive control over credentials reduces the internal risk surface.
To be clear: "aligned with ISO 27001 controls" does not mean ISO 27001 certification. LoginMaster is not a standard OpenID Provider: integration happens via SDKs and REST APIs, with OAuth2/OIDC SSO to providers such as Google Workspace and Entra ID.
We'll set up a technical session to review roles, session revocation, MFA policies and the encryption model together, with honest answers on limits and roadmap.
Talk to our team