Description of software services - Frontline Identity by Flip
Last updated: 08/06/2026
Frontline Identity by Flip provides the following functions for the activation, authentication and management of user identities:
Activation
Activation by invite code. New users activate their access by entering a short, time-limited activation code. The code can be generated individually or in bulk for multiple users and distributed in various ways. After entering the code, the user sets up their login and completes the activation.
Activation by QR code. Users can activate their access by scanning a QR code. The QR code points to the activation process, so that manual entry of addresses or codes on the end device is not required.
Manager-based verification. Local managers can verify the identity of users and generate activation codes for their team, where configured by the Customer. The same route can also be used to reset a user’s login, so that a password reset is also possible for users without a stored email address. Activation of new users can thus be carried out in a decentralised manner and without direct involvement of central IT.
Authentication
Passwordless login with passkeys. Users can log in without a password using a passkey. Confirmation is provided via the biometric methods of the end device (fingerprint or facial recognition) or the device PIN. Passkeys follow the FIDO2/WebAuthn standard and can be synchronised between a user’s devices and used across devices (cross-device login) via the common standards; a change of device therefore does not require re-registration. The login is phishing-resistant, as the passkey is bound to the respective application and cannot be used on fake pages. An additional password is not required.
Login by username and password. Login is also possible using a username and password. The username can be an email address or another identifier, such as an employee number. Users can reset their password themselves via a password reset function, provided that a valid email address is stored; they receive a reset link at this email address on request. Alternatively, the reset can be carried out via manager-based verification, so that users without an email address can also reset their password.
Certificate-based authentication (also for shared devices). Flip supports certificate-based authentication as a login method. The certificates are generally provided via a mobile device management (MDM) system. The Customer decides whether a certificate is issued per device or per user (personalised). In combination with a personal password or PIN, this results in two-factor login; with personalised certificates, both factors are user-bound. This method in particular enables the personalised login of several users on shared devices and can be restricted to correspondingly managed devices.
Management of user identities
Custom roles and permissions. Access to functions and data is controlled via permissions that are grouped into roles and assigned to users. Organisations can adapt the predefined roles by enabling or disabling individual permissions, and can also define their own roles. Users and other resources can be mapped via user groups along the organisational structure (companies, sites, departments, teams). Permissions can be granted organisation-wide or restricted to individual user groups and are inherited by subordinate groups within the group hierarchy. The fine-grained permission model allows administrative tasks (user, role and access management) to be split across separate roles. Permissions can be restricted to individual user groups, so that local managers administer only their own area (delegation of roles). Changes to roles and permissions are recorded in the audit log and are thus retained historically. For recertification, the permissions granted can be read out via the admin console and via API or audit-log export and can thus be integrated into existing IGA/GRC tools.
Group-based access control for connected applications. Access to connected third-party applications can be controlled on the basis of user groups. It can be defined which user groups may log in via single sign-on to which connected application. In this way, application access is centrally governed along the organisational structure.
Session and token management and lifecycle control. The validity period of sessions and tokens can be configured. Through control of the user account lifecycle (locking or deactivating an account), a user’s access can be revoked, whereby existing sessions and tokens become invalid. This control can be carried out both manually in the administration interface and automatically via SCIM or API.
Configuration of user attributes. Attributes can be defined and maintained for users. These attributes can be used, among other things, for the assignment of permissions and for handover to connected applications.
SSO provision. Frontline Identity by Flip can act as an identity provider for connected third-party applications. Administrators can configure the connection themselves, so that users can log in to connected applications with their Flip identity via single sign-on (SSO). The supported authentication protocols are OIDC (OpenID Connect) and SAML (Security Assertion Markup Language).
Connection of an existing identity provider. An identity provider operated by the Customer can be connected, so that authentication takes place via it. For users connected via an external identity provider, login via that provider can be offered as an additional login option. The supported authentication protocols are SAML and OIDC.
Connection of directory services. For simplified user management, an existing directory service can be connected on request, whereby synchronisation of the users is established.
Automated user provisioning and deprovisioning (SCIM / API). Users can be automatically provisioned, synchronised and deactivated again from a central directory (joiner-mover-leaver). For this, the SCIM 2.0 (System for Cross-domain Identity Management) protocol and an API are supported. In this way, an employee’s access is automatically revoked upon departure. Flip acts as a SCIM target (inbound). Errors are returned to the sending system via standardised API error codes; the retry logic lies with the source-side system. The availability of the interface is monitored and can be viewed at getflip.com/status/.
Management via the admin console. Identities and their login methods can be managed via an administration interface. Administrators can create, edit and deactivate users and manage their access, roles and permissions.
Operation, security and data protection
Audit logs. Identity-related operations are logged (login attempts, changes to roles and permissions and other identity-related actions). The logs are tamper-proof: entries can neither be modified nor individually deleted by administrators. Personal data is removed in accordance with the section “Retention and export”. The logs are searchable and available in JSON format via export and via an API for integration into SIEM tooling. Retention is governed by the section “Retention and export”. In particular, the following are logged: the user account lifecycle (creation, change, locking/deactivation, deletion), profile and attribute changes (including self-service), groups and group memberships, login methods and credentials (password, passkey, TOTP), API clients and provisioning (SCIM), and role and permission changes.
Availability reporting. The availability status of Frontline Identity by Flip can be viewed at any time at getflip.com/status/.
Hosting in the cloud. Hosting of the service takes place in GDPR-compliant data centres in Germany.
Retention and export
The retention periods for the individual data categories are set out in the table below. Retention periods marked as configurable can be set by the Customer within the limits provided for. Customer content can be exported in the formats and via the routes stated. In all other respects, deletion after the end of the contract is governed by the main agreement and the data processing agreement.
Data category | Retention | Configurable | Export |
Audit logs | Until the tenant is deleted; personal data relating to a user is removed 14 days after that user has been marked for deletion | No | Export via API (JSON), limited to the last 12 months |
User accounts after deactivation | Until the tenant is deleted | No | Export via API (JSON) |
User accounts after being marked for deletion | 14 days | No | Export via API (JSON) |
Sessions and access tokens | Access tokens 30 minutes; configurable for integrations, max. 24 hours. Sessions max. 730 days, max. idle time 120 days | In part (integration tokens and session duration) | No export |
Activation codes | Stored as a hash only; until expiry or redemption | Yes, currently max. 90 days | No export |
Activation codes from bulk generation (download) | Max. 1 day | No | Export via API (JSON) |
Credentials (password, passkey, TOTP) | Until changed, otherwise 14 days after the user has been marked for deletion; password history according to the configured number | Password history only | No export |
Failed login attempts and lockout counters | Login attempts in the audit log; lockout counters 10 minutes | No | No export |
SSO assertions and attributes passed to connected applications | For the duration of the session, max. 730 days | Via the session duration | No export |
SCIM provisioning logs | In the audit log | No | Via the audit log export |
API clients | In the audit log | No | Via the audit log export |
Backups | Point-in-time recovery 7 days; Offsite backup 30 days | No | No export. |
For the data categories marked above as “No export”, no self-service export function is available; where they contain Customer Content, the Provider makes it available upon the Customer’s request via support in a structured, commonly used and machine-readable format. The entries in the “Export” column refer to the export functions available during the term of the contract; the Customer’s rights under the main agreement (switching support) and under the data processing agreement remain unaffected.
System requirements
The following minimum requirements apply to the operating systems and browsers of end devices:
Operating systems
Windows: last 3 major versions
macOS: last 3 major versions
iOS: last 3 major versions
Android: last 6 major versions
Flip app: iOS last 2 major versions, Android last 2 major versions
Browsers
Chrome desktop & mobile: last 3 major versions
Edge desktop: last 3 major versions
Firefox desktop: last 3 major versions
Safari desktop: last 3 minor versions
Passwordless login with passkeys requires end devices that support FIDO2/WebAuthn and platform authenticators (biometric methods or device PIN).
Supported standards and protocols
SAML 2.0 (Security Assertion Markup Language)
OIDC (OpenID Connect)
SCIM 2.0 (System for Cross-domain Identity Management)
FIDO2 / WebAuthn (passkeys)
TOTP (time-based one-time password, RFC 6238)
Legal framework
This software service description sets out the characteristics of the Frontline Identity by Flip software service. Which functions are owed in a specific case follows from the offer in conjunction with the main agreement. Frontline Identity by Flip requires the use of the Flip platform; the software service description of the Flip platform applies in addition. The service quality and availability owed are governed by the Frontline Identity Service Level Agreement. The Provider may develop the service further within the scope of the contractual provisions. The current version of this software service description is available at https://www.getflip.com/legal/softwaredescription-identity/.