Usage obligation

The usage obligation stipulates that applications must, in accordance with the framework conditions defined in Directive W008, obtain electronic identities, or more precisely the authentication service based on them, from the IAM Bund standard service, namely from the eIAM service of the FCh DTI and, for dedicated use cases, from the SSO Portal of the FDJP.

For applications whose authentication service must be obtained through eIAM, eIAM provides the designated access to the permitted identity providers. This applies regardless of whether eIAM is connected directly by the target application or, where permitted, indirectly through a portal, an intermediary IAM system or another brokering component.

Where the Swiss state e-ID is used for the purpose of authenticating a person to a target application subject to the usage obligation, this is done through the AGOV standard-service component. The e-ID may not be used directly, bypassing AGOV, as an application-specific login or authentication means. For the central Federal Administration, AGOV is generally obtained through eIAM; AGOV «direct only» is permitted solely where an exemption has been granted for this purpose.

Consequently, other means of obtaining the required authentication service, for example direct connection of identity providers (IdPs) to applications, middleware, SaaS or other target systems, as well as application-specific login procedures, require an exemption from the FCh DTI where the usage obligation applies and Directive W008 does not provide otherwise.

Authorisation management (Access Management) may also be obtained as part of the IAM Bund standard service. This must be distinguished from application-internal fine-grained authorisation, in particular the management of permissions for functions and data within an application. Under Directive W008, such fine-grained authorisation is not part of the IAM Bund standard service and may be located in the target application, middleware, SaaS or another system intended for this purpose.

This regulation pursues the objectives of optimised economic efficiency, defined security and the promotion of digitalisation of administrative processes through the interoperability of electronic identities in accordance with the once-only principle.

The following provisions apply to IAM services that fall within the scope of the IAM Bund standard service under Directive W008 and are subject to the usage obligation. The exclusions expressly provided for in Directive W008 and validly granted exemptions remain reserved.

The usage obligation is based on the Digitalisation Ordinance (DigiV) and Directive W008. For IAM services of the central Federal Administration that are subject to the usage obligation, the standard service is the prescribed provisioning path. Exemptions limited to an administrative unit or an application are decided by the FCh DTI in accordance with W008 and process P035 and are time-limited.

For web applications and native mobile apps subject to the usage obligation, the authentication service must generally be obtained through eIAM. This also applies to SaaS and other cloud operating models, irrespective of whether a solution is operated or used internally, externally, in Microsoft Azure, at another hyperscaler or on a mobile device managed by the Federal Administration.

Microsoft Entra ID is not an alternative to eIAM for user authentication of a specialist application, web application, SaaS solution or native mobile app subject to the eIAM usage obligation. Direct federation of such a target application with Entra ID, or use of Entra ID as its login or authentication service, is therefore not permitted unless an applicable exclusion or exemption exists.

This must be distinguished from Microsoft 365 services and Microsoft 365 apps provided within the office automation standard service and approved in accordance with the applicable requirements, in particular AR009 and E031. Their IAM provisioning is governed by the specific requirements of the office automation standard service. This M365-specific arrangement does not constitute general approval of Entra ID as an authentication service for other applications.

In particular, a specialist application or native mobile app does not become a Microsoft 365 application or cease to be subject to the eIAM usage obligation merely because it is installed on a managed device, distributed, configured, protected or managed using Microsoft Intune, registered in an Entra ID tenant, uses Microsoft libraries or is operated in Microsoft Azure. Where the application is subject to the eIAM usage obligation, its user authentication must be performed through eIAM.

Unless an applicable exclusion under W008 or a required and previously granted exemption exists, the following are prohibited in particular:

• application-specific procedures for initially or subsequently establishing a user's identity, for example using username/password accounts maintained within the application or other application-specific credentials, where these are used instead of the required authentication through eIAM;
• the direct connection of an internal or external identity provider to a target application subject to the usage obligation, a native mobile app, middleware, portal layer, SaaS solution or another target system while bypassing eIAM;
• the direct federation of a specialist application, web application, SaaS solution or native mobile app subject to the usage obligation with Microsoft Entra ID, or use of Entra ID as that application's login or authentication service outside the M365 arrangement provided within the office automation standard service;
• the use of Microsoft Entra ID as the login or authentication service for a native mobile app solely because that app is installed, distributed, configured, protected or managed using Microsoft Intune;
• the use of Microsoft Entra ID as the login or authentication service for a specialist application solely because it is operated in Microsoft Azure, registered in an Entra ID tenant or uses other services of the Microsoft cloud ecosystem;
• direct authentication of users of a web application or native mobile app subject to the usage obligation against Active Directory, LDAP, Kerberos or comparable directory or authentication services while bypassing eIAM; under the eIAM requirements, direct use of Kerberos by web applications and native mobile apps requires an exemption;
• the direct connection of sector IdPs or other identity providers intended to be obtained through eIAM to target systems subject to the usage obligation or intermediary IAM systems instead of obtaining them through eIAM;
• portal-proprietary login procedures or direct connections of identity providers at a portal layer subject to the usage obligation; permitted abstraction of the eIAM connection by a portal layer does not remove the usage obligation;
• the use of AGOV «direct only», i.e. direct connection of AGOV to a target application or an intermediary IAM system without eIAM in between, unless a prior exemption has been granted for this purpose for the central Federal Administration; this also applies to native mobile apps;
• the direct use of the Swiss state e-ID as an application-specific login or authentication means for a target application or native mobile app subject to the usage obligation while bypassing AGOV or the IAM provisioning path prescribed for the application concerned;
• placing an IAM, identity-broker, federation or single sign-on system upstream or in between where this replaces or bypasses eIAM as the required source of the authentication service;
• the creation of separate login islands for individual specialist applications, native mobile apps, SaaS solutions, projects, organisational units or user groups where their authentication service is subject to the usage obligation of the IAM Bund standard service.

Application-specific authorisation management (Access Management) is not affected where it concerns authorisation and, in particular, fine-grained authorisation within the application. User objects, roles, permissions, business attributes and other information required for authorisation may, in accordance with the applicable requirements, be maintained in the target application, middleware, SaaS or another system intended for this purpose. This must not, however, result in the required authentication service being replaced by a proprietary or different IAM provisioning arrangement.

For native mobile apps, a distinction must also be made between authentication against eIAM and local access to a login state that has already been established through eIAM and persisted. Login persistence is permitted in accordance with the eIAM requirements. Renewed access to such a persisted login state may be released locally using device protection, in particular biometrics or the device PIN. Such local re-authentication is neither an alternative identity provider nor a circumvention of the eIAM usage obligation. Where renewed authentication against the IAM system is required, it is again performed through eIAM.

Indirect eIAM connections through portals, intermediary IAM systems or comparable brokering components are also permitted where they convey the authentication service obtained from eIAM to the target application and neither replace nor bypass eIAM as the required authentication instance. The same applies to authentication bridges that connect an otherwise incompatible target application to eIAM.

The impermissible use of Entra ID as an alternative user-authentication service must also be distinguished from technical use of the Microsoft cloud ecosystem that is permitted under the applicable requirements. AR015 governs, in particular, Entra ID accounts, application registrations, service principals, tenants and other components required for operating cloud solutions. Their technical use does not in itself constitute alternative user authentication. It does not, however, authorise Entra ID to be used instead of eIAM as the identity provider or authentication service for a target application subject to the eIAM usage obligation. The requirements in AR015 concerning identity brokering and federation through the IAM standard service continue to apply.

The decisive factor is therefore the function, not the product, operating platform or operating location: where user authentication is subject to the usage obligation of the IAM Bund standard service, it must be performed through the service designated for that purpose within the standard service. A different authentication path is permitted only where the IAM service concerned is not subject to the usage obligation under W008 or where the required exemption has been granted in advance.

Exemptions are governed by Directive W008 and process P035. Exemptions limited to an administrative unit or an application are decided by the FCh DTI and are time-limited.

Exemptions for IAM provisioning of web applications and native mobile apps outside the corresponding Federal Administration standard service are granted for pilot operations with a narrowly limited duration.

For IAM provisioning of web applications and native mobile apps in productive operation, the published eIAM requirements provide that exemptions are generally not granted, even for a small number of users or low protection requirements, except in cases of absolute technical impossibility or an urgent situation. The mere fact that a product already has its own login mechanism or that its manufacturer supports only another IAM solution does not in itself constitute grounds for an exemption.

AGOV «direct only» is provided for the central Federal Administration as a very rare case requiring approval. Without the corresponding prior approval, AGOV is obtained through «full» eIAM.

Procurements of software, SaaS and other cloud solutions, etc. must, in accordance with , be fully aligned with connectivity to eIAM. For solutions subject to the usage obligation, connectivity to the prescribed standard service is a mandatory criterion.

Where ICT solutions are procured, including cloud solutions such as SaaS, which cannot be connected to eIAM within the eIAM standard, the application owner is required to have an authentication bridge in the form of an adapter developed and operated. See .

An exemption granted applies solely to the scope specified in the exemption and for the specified duration. It does not constitute general approval of the IAM provisioning pattern used for other applications, organisational units or subsequent projects.

Uniform IAM provisioning across the Federal Administration's application landscape is the basis for successful digitalisation of processes. An accumulation of small applications with proprietary IAM provisioning must therefore be avoided or consolidated.