Regulatory compliance built into the architecture
LoginMaster architecturally separates personal data (which resides on the customer's Tenant) from the Cloud, which handles only pseudonymized and encrypted data. An architecture that structurally limits the provider's access to data and natively supports GDPR, NIS2, and ISO 27001:2022 requirements.
EU Regulation 2016/679
Privacy by design: personal data resides on the customer's Tenant. The Cloud handles only pseudonymized or encrypted data.
EU Directive 2022/2555
Multi-layer cryptography, configurable 2FA, login tracking, and cryptographic isolation between tenants.
ISO/IEC 27001:2022
Role-based access control, dedicated cryptographic keys, and encrypted communications.
Supporting compliance with the General Data Protection Regulation
The GDPR (EU Regulation 2016/679) defines the fundamental principles for personal data protection in Europe. In LoginMaster, users' personal data resides primarily on the customer's Tenant. The Cloud handles only pseudonymous identifiers and encrypted payloads, structurally limiting access by the provider. This architectural separation natively supports several requirements of the regulation.
Data minimization
Only pseudonymous identifiers and encrypted payloads transit through the Cloud, never personal data in clear text. Users' identifying data resides on the customer's Tenant. Subject types (user and device) and API keys are structured to manage only the information pertinent to each use case.
Right to erasure
LoginMaster enables the deletion of user data upon request, within the limits set by Art. 17(3) -- for example, legal retention obligations or the exercise of rights in legal proceedings. Retention periods for logs and audit trails are documented in the data retention policy.
User autonomy
In LoginMaster, no administrator can reset the password, change the email, or disable the 2FA of a user. The user maintains full control over their own credentials and security settings, in line with the principles of transparency and fairness in data processing.
Privacy by design
Personal data resides primarily on the customer's Tenant. The Cloud handles only pseudonymized or encrypted data, with an architectural separation that structurally limits access by the provider. Each tenant and each project operate with their own independent cryptographic keys.
Security of processing
Cryptography applied at every level: project-tenant, tenant-cloud, client-API. Dual-signature tokens (Tenant + Cloud) and cryptographic isolation between tenants. Periodic testing and evaluation procedures for the effectiveness of technical measures, with data availability and recovery mechanisms in the event of an incident.
Access tracking
LoginMaster records recent access events and failed attempts for each user. This tracking enables the identification of suspicious activity and supports the principle of integrity and confidentiality of personal data set forth in the regulation.
Alignment with the NIS2 cybersecurity directive
The NIS2 directive (EU 2022/2555) introduces cybersecurity obligations for essential and important entities in the European Union. LoginMaster provides concrete technical tools that contribute to meeting several requirements of Article 21: multi-layer cryptography, two-factor authentication, access tracking, and cryptographic isolation between tenants.
Risk analysis and information system security policies
LoginMaster adopts a multi-layer security architecture: each tenant is isolated with unique cryptographic keys, each project has its own keys, and communications are encrypted at every step (project-tenant, tenant-cloud, client-API). The deployment integrates with the customer's risk assessment and governance policies, contributing to attack surface reduction.
- Unique cryptographic keys per tenant and project
- Encrypted communications at every level
- Complete isolation between tenants
- Integrable with the customer's risk management policies
Incident handling
LoginMaster records recent access events and failed authentication attempts for each user. Logs are integrable with the customer's SIEM systems to support the incident response plan, escalation procedures, and notification processes required by the directive.
- Recent login history per user
- Failed attempt logging
- Logs integrable with SIEM and alerting systems
- Support for incident response and notification processes
Cryptography and key management
All communications in LoginMaster are encrypted: between the project and the tenant, between the tenant and the cloud, and between the client and the APIs. The Cloud handles only encrypted data and pseudonymous references. Tokens are protected by dual signature (Tenant + Cloud). Cryptographic keys are subject to management policies that include rotation, revocation, and lifecycle control.
- Encrypted communications at every level
- Dual-signature tokens (Tenant + Cloud)
- Key rotation and revocation policies
- Documented key lifecycle management
Multi-factor authentication
LoginMaster offers per-project configurable 2FA with three levels: disabled, optional, or mandatory. Disabling 2FA requires direct user action through an authenticated procedure; administrators cannot disable it on behalf of others. Documented recovery procedures are available for restoring access in case of second-factor loss.
- Per-project configurable 2FA
- Three modes: disabled, optional, mandatory
- Deactivation only through user-authenticated procedure
- Documented recovery procedures for access restoration
Supporting ISO/IEC 27001:2022 controls
ISO/IEC 27001 is the international reference standard for information security management systems. LoginMaster supports several Annex A controls through its native identity management, cryptography, and access monitoring capabilities.
Identity management
LoginMaster manages identities and access with configurable roles per project. It supports two subject types (user and device) and API keys as a server-to-server communication method. By Q2 2026, SSO integration with Google Workspace and Microsoft Entra ID will be available for centralized authentication.
- Role-based access management
- Configurable permissions at the project level
- Subjects (user, device) and API keys for communication
- SSO with Google Workspace and Microsoft Entra ID (Q2 2026)
Use of cryptography
Each tenant and each project have their own cryptographic keys. Tokens are protected by dual signature (Tenant + Cloud). The Cloud handles only encrypted data and pseudonymous references. Keys are subject to management policies with documented rotation and revocation.
- Unique cryptographic keys per tenant and project
- Dual-signature tokens (Tenant + Cloud)
- Encrypted credentials with split architecture
- Key management policies with rotation and revocation
Logging and monitoring
LoginMaster records recent access events and failed attempts for each user, providing visibility into authentication activity. Logs are integrable with the customer's SIEM systems for centralized monitoring.
- Recent login tracking
- Failed attempt logging
- Authentication activity monitoring
- Logs integrable with customer SIEM
Information transfer
All LoginMaster communications are encrypted at every level of the architecture: between project and tenant, between tenant and cloud, and between client and API. Personal data resides primarily on the Tenant: the Cloud handles only encrypted data and pseudonymous references.
- Encrypted project-tenant communications
- Encrypted tenant-cloud communications
- Encrypted client-API communications
- Split architecture for credentials
Regulatory compliance table
How LoginMaster's actual features address the key regulatory requirements of GDPR, NIS2, and ISO 27001.
| Requirement | Regulation | How LoginMaster meets it |
|---|---|---|
| Data minimization | GDPR Art. 5(1)(c) | Only pseudonymous identifiers and encrypted payloads transit through the LoginMaster Cloud, never personal data in clear text. Users' identifying data resides on the customer's Tenant, minimizing exposure and limiting the processing surface on the Cloud. |
| Right to erasure | GDPR Art. 17 | LoginMaster enables the deletion of user data upon request, within the limits set by Art. 17(3) (legal retention obligations, exercise of rights in legal proceedings). Retention periods for logs and audit trails are documented in the data retention policy. |
| Privacy by design | GDPR Art. 25 | Architecture designed so that personal data resides primarily on the customer's Tenant. The Cloud handles only pseudonymized or encrypted data. Unique cryptographic keys for each tenant and project, with architectural separation between the customer environment and the central service. |
| Security of processing | GDPR Art. 32 | Multi-layer cryptography (project-tenant, tenant-cloud, client-API), cryptographic isolation between tenants, and dual-signature tokens. Periodic testing and evaluation procedures for the effectiveness of technical measures. Data availability and recovery mechanisms for personal data in the event of an incident. |
| Risk analysis and information system security policies | NIS2 Art. 21(2)(a) | Multi-layer security architecture with cryptographic isolation between tenants, unique keys per project, and encrypted communications at every level. LoginMaster deployment integrates with the customer's risk assessment and governance policies. |
| Incident handling | NIS2 Art. 21(2)(b) | Login tracking with access history, failed attempt monitoring, and authentication activity logging. LoginMaster logs are integrable with the customer's SIEM systems to support the incident response plan and escalation and notification procedures required by the directive. |
| Cryptography and encryption | NIS2 Art. 21(2)(h) | Encrypted communications at every level of the architecture. The Cloud operates exclusively on encrypted and unreadable data. Dual-signature tokens (Tenant + Cloud). Cryptographic keys are subject to management policies that include rotation, revocation, and lifecycle control. |
| Multi-factor authentication | NIS2 Art. 21(2)(j) | Per-project configurable 2FA with three modes: disabled, optional, or mandatory. Disabling 2FA requires direct user action through an authenticated procedure; administrators cannot disable it on behalf of others. Documented recovery procedures are available for access restoration. |
| Identity management | ISO 27001:2022 5.15 | Role-based access management at the project level, with subjects (user and device) and API keys for server-to-server communication. SSO via Google Workspace and Microsoft Entra ID coming by Q2 2026. |
| Use of cryptography | ISO 27001:2022 8.24 | Unique cryptographic keys per tenant and per project, dual token signing, and credential encryption with split architecture. Key management policies with documented rotation and revocation. |
Frequently Asked Questions About Compliance
Users' personal data resides primarily on the customer's Tenant. The LoginMaster Cloud handles only pseudonymous identifiers and encrypted payloads, structurally limiting access by the provider. Each tenant and each project have unique cryptographic keys and tokens are protected by dual signature (Tenant + Cloud).
Yes. LoginMaster is designed according to privacy by design principles: users' personal data resides primarily on the customer's Tenant. The Cloud handles only pseudonymized or encrypted data, structurally limiting access by the provider. The split architecture and multi-layer cryptography protect personal data during processing. LoginMaster also supports data deletion upon request, within the limits set by Art. 17(3).
LoginMaster addresses several NIS2 directive requirements: it offers encrypted communications at all levels of the architecture, per-project configurable two-factor authentication, login and failed attempt tracking with logs integrable into the customer's SIEM systems, key management policies with rotation and revocation, and a multi-layer security architecture with cryptographic isolation between tenants.
LoginMaster supports ISO 27001:2022 controls related to identity management (5.15) with configurable roles and subject types, use of cryptography (8.24) with unique keys per tenant and project and key management policies, logging and monitoring (8.15) with login tracking and SIEM integration, and information transfer (5.14) with encrypted channels at every level.
2FA in LoginMaster is configurable for each individual project with three modes: disabled, optional, or mandatory. Deactivation requires direct user action through an authenticated procedure; administrators cannot disable it on behalf of others. Documented recovery procedures are available for restoring access in case of second-factor loss.
Yes, LoginMaster supports SSO with Google Workspace and Microsoft Entra ID, enabling users to authenticate with their existing corporate credentials. This simplifies access management and reduces the number of credentials to manage, in line with security best practices.
Ready to strengthen your security for your organization?
Contact our team to discover how LoginMaster can support your organization in achieving GDPR, NIS2, and ISO 27001 compliance goals, with a concrete and verifiable security architecture.