Published on 6 August 2026

AGOV for cloud, SaaS and Hyperscaler architectures

Interaction with Microsoft Entra ID, Microsoft 365, AWS, Google Cloud and other platforms

1. Context

AGOV is the authentication service for Swiss public authorities. Target applications can be connected to AGOV using OpenID Connect, or OIDC, or SAML 2.0, either directly or through an existing identity and access management system.

AGOV is not tied to a particular operating model. A target application may be operated:

  • in a data centre of the responsible authority
  • by a public or private service provider
  • in a private cloud
  • as software as a service
  • on a hyperscaler platform
  • or within a hybrid or cross-organisational architecture

The target application itself, or an upstream IAM component, must support an OIDC or SAML profile that is compatible with AGOV.

AGOV does not preclude the connection of SaaS, cloud or hyperscaler solutions. Technical connectivity must, however, be distinguished from the legal, security and organisational permissibility of the relevant operating model.

2. Identity, organisational context and authorisation

AGOV authenticates natural persons. It confirms to a connected target application which person has signed in and the authentication or identity-verification quality with which the sign-in was performed.

An AGOV account always represents exactly one natural person. In particular, it does not represent:

  • membership of an authority or organisation
  • an official or professional function
  • authority to represent an organisation
  • a business role
  • a cloud licence
  • an application entitlement
  • or a resource assignment

This information and the related decisions remain with the responsible authority, its organisational IAM, the cloud platform or the relevant application.

The fundamental allocation of responsibilities is as follows:

AGOV authenticates the natural person.

The organisational IAM associates the person with an organisation, function or role.

The cloud platform manages its platform-specific accounts, licences, groups, roles and tokens.

The application decides on the specific business authorisation.

3. Integration models

3.1 Direct connection

A target application may be connected directly to AGOV as an OIDC relying party or SAML service provider.

Application ↔ AGOV

This model is particularly suitable for applications developed by public authorities, e-government portals and standard solutions with a freely configurable OIDC or SAML connection.

3.2 Connection through an existing IAM or identity broker

Multiple target applications may be connected to AGOV through a common IAM component.

Applications ↔ IAM or identity broker ↔ AGOV

The intermediary layer may in particular:

  • align different protocol profiles
  • transform claims and attributes
  • add internal person identifiers
  • obtain organisational affiliations from separate directories
  • assign groups and roles
  • combine multiple applications within an SSO domain
  • encapsulate product-specific characteristics from AGOV.

Connection through an existing IAM system forms part of the intended AGOV integration model.

3.3 Connection through a cloud platform IAM

A cloud platform IAM may act towards AGOV as a relying party or as an intermediary identity layer.

Cloud application ↔ Cloud IAM ↔ AGOV

In this model, AGOV authenticates the natural person. The cloud platform subsequently issues its own tokens and manages its platform-specific accounts, roles and access decisions.

4. Protocol support and specific interoperability

Support for OIDC or SAML provides the technical basis for a connection. For a specific integration, it must also be verified that the profiles and processes used by AGOV and the relevant target platform are compatible.

The following aspects must in particular be considered:

  • OIDC or SAML profiles
  • issuer, audience and entity IDs
  • redirect and callback procedures
  • stable person identifiers
  • claims and attributes
  • signing and encryption procedures
  • key and certificate rotation
  • session duration and re-authentication
  • authentication quality and step-up
  • single logout
  • requirements of browsers, mobile applications, desktop clients or command-line tools.

Differences in individual areas do not in themselves preclude an integration. Depending on the circumstances, they may be addressed through configuration, an extension of the integration profile, further development of AGOV or the use of a controlled identity broker.

5. Microsoft Entra ID e Microsoft 365

Microsoft 365 uses Microsoft Entra ID as its directory, token, licensing and access platform.

A Microsoft 365 domain may in principle be federated with an external SAML identity provider. Microsoft uses a specific integration profile with defined requirements for endpoints, identifiers, claims, signatures and client procedures.

A possible integration model is:

Microsoft 365 ↔ Microsoft Entra ID ↔ AGOV or identity broker

AGOV authenticates the natural person. Microsoft Entra ID remains responsible in particular for:

  • Microsoft 365 user accounts
  • User Principal Names
  • licences
  • groups
  • roles
  • application assignments
  • Microsoft tokens
  • Microsoft Graph
  • Microsoft-specific access policies.

Direct federation between AGOV and Microsoft Entra ID requires the profiles and processes used to be compatible. Where a product-specific requirement is not met directly, a suitable intermediary layer may be used or a corresponding development requirement may be submitted for AGOV.

Federation of a Microsoft 365 domain must be distinguished from Microsoft Entra External ID scenarios. These relate in particular to access by external persons to selected Entra-protected resources and must be assessed separately from both a technical and organisational perspective.

6. Amazon Web Services

Different AWS use cases must be distinguished.

6.1 Access to the AWS management layer

AWS IAM Identity Center may be used for person-specific access to AWS accounts and the AWS Management Console. IAM Identity Center can delegate authentication to an external SAML identity provider.

AWS Management Console ↔ AWS IAM Identity Center ↔ AGOV or identity broker

AGOV authenticates the natural person. AWS manages in particular:

  • AWS accounts
  • permission sets
  • IAM roles
  • groups
  • resource policies
  • AWS sessions and AWS tokens.

SAML federation does not replace the provisioning of the users, groups and role assignments required in AWS. These are managed separately, for example through SCIM, manual administration or an upstream organisational IAM.

6.2 Applications operated on AWS

An application operated on AWS may be connected directly to AGOV using OIDC or SAML.

Application on AWS ↔ AGOV

Amazon Cognito may alternatively be used as an intermediary layer.

Application on AWS ↔ Amazon Cognito ↔ AGOV

In this model, Cognito issues product-specific tokens and maps attributes for the application.

6.3 Technical workloads

Technical processes, servers, containers, functions and service accounts are not authenticated through AGOV. The relevant procedures for technical identities, short-lived credentials and workload federation must be used for such workloads.

7. Google cloud

Through Workforce Identity Federation, Google Cloud enables the integration of external OIDC or SAML identity providers for natural persons.

Google Cloud ↔ Workforce Identity Federation ↔ AGOV

AGOV authenticates the natural person. Google Cloud maps the transmitted identity and permitted attributes to its own IAM roles and resource permissions.

Google Cloud remains responsible in particular for:

  • workforce pools
  • attribute mappings
  • principal sets
  • Google Cloud IAM roles
  • resource policies
  • short-lived Google tokens.

Workforce Identity Federation for natural persons must be distinguished from Workload Identity Federation for technical processes.

Google Cloud Workforce Identity Federation must also not be equated with Google Workspace. Connecting Google Workspace is a separate product scenario.

8. Other cloud and saas platforms

8.1 Oracle Cloud Infrastructure

OCI IAM Identity Domains can delegate authentication to an external SAML identity provider.

Oracle Cloud ↔ OCI IAM Identity Domain ↔ AGOV or identity broker

Groups, roles, policies and cloud permissions remain in OCI or the responsible organisational IAM.

8.2 SAP Business Technology Platform

Depending on the service and architecture, SAP BTP may be connected directly to AGOV using SAML or indirectly through SAP Cloud Identity Services.

Direct model:

SAP BTP application ↔ AGOV

Intermediated model:

SAP BTP application ↔ SAP Cloud Identity Services ↔ AGOV

SAP-specific role collections, business roles and permissions remain outside AGOV.

8.3 Salesforce

Salesforce may operate as a SAML service provider towards AGOV or an identity broker.

Salesforce ↔ AGOV or identity broker

User objects, profiles, permission sets, licences and business permissions remain in Salesforce or the responsible organisational IAM.

8.4 ServiceNow and other SaaS solutions

ServiceNow and many other SaaS products support the connection of external identity providers using OIDC or SAML.

Where a SaaS solution permits the customer to define its own OIDC or SAML identity provider, a direct or intermediated connection to AGOV may in principle be assessed and implemented.

9. Overview

  • Platform or scenario
  • Possible AGOV connection
  • Remaining responsibility
  • Internally developed application
  • Directly using OIDC or SAML
  • Business roles, permissions, sessions and business data
  • Microsoft 365
  • Through Microsoft Entra ID, directly where profiles are compatible or through a broker
  • Accounts, UPNs, licences, groups, roles and Microsoft tokens
  • AWS Management Console
  • SAML through AWS IAM Identity Center
  • AWS accounts, permission sets, IAM roles and provisioning
  • Application on AWS
  • Directly using OIDC or SAML or through Amazon Cognito
  • Application profiles, AWS resources and business permissions
  • Google Cloud
  • OIDC or SAML through Workforce Identity Federation
  • Attribute mapping, IAM roles and resource policies
  • Oracle Cloud
  • SAML through OCI IAM Identity Domains
  • OCI groups, roles and policies
  • SAP BTP
  • Directly using SAML or through SAP Cloud Identity Services
  • Role collections and SAP business roles
  • Salesforce
  • SAML directly or through a broker
  • Profiles, permission sets, licences and business permissions
  • Other SaaS solutions
  • OIDC or SAML following assessment of the specific integration profile
  • Product-specific accounts, roles, data and processes

10. Requirements for AGOV

AGOV is aligned with the needs of Swiss public authorities and is developed accordingly.

Where a relying party requires, for the connection of a cloud or SaaS platform:

  • an additional claim
  • a specific attribute
  • a supplementary signing variant
  • specific protocol behaviour
  • an extension of an existing integration profile
  • or another standards-based function

the requirement may be submitted to the Swiss Federal Chancellery through the established connection, exchange and governance channels.

Product-specific interoperability requirements form part of the regular development of AGOV. They do not in themselves constitute a reason to exclude the relevant platform.

The Federal Chancellery assesses such requirements in particular with regard to:

  • security
  • data protection
  • compliance with standards
  • benefits for multiple authorities and relying parties
  • effects on existing integrations
  • operational viability
  • costs
  • avoidance of unnecessary vendor dependencies

Further development of AGOV is particularly appropriate where a requirement is based on open standards, improves interoperability and does not transfer business roles, organisational affiliations or product-specific permissions into AGOV.

Where a requirement is relevant only to a single product or is strongly proprietary, the use of a controlled identity broker may be the more appropriate solution.

11. Hyperscalers, digital sovereignty and e-government

11.1 Scope of responsibility of AGOV

AGOV governs authentication and the IAM-specific conditions required for it.

The use of AGOV does not determine whether an application may be operated locally, in a private cloud, as a SaaS solution or on a hyperscaler platform.

For this assessment, AGOV does not establish additional substantive cloud or sovereignty requirements beyond the IAM framework applicable to AGOV, in particular the Ordinance on Identity Management Systems and Directory Services of the Confederation (Verordnung
über Identitätsverwaltungs-Systeme und Verzeichnisdienste des Bundes, IAMV).

(IAMV)

A connection to AGOV therefore constitutes neither approval nor exclusion of a particular cloud platform.

11.2 Responsibility of the relying party

The authority responsible for the business process, or the relying party, assesses the permissibility of the selected operating model.

It remains responsible in particular for:

  • the legal basis of the business process
  • the purpose and proportionality of data processing
  • selection of the cloud, SaaS or platform solution
  • classification and protection requirements of the data
  • assignment of roles and access rights
  • information security
  • data protection
  • commissioned data processing
  • any sub-processors
  • disclosures of data abroad
  • retention and deletion
  • logging and traceability
  • business continuity
  • exit and migration capability
  • information provided to the persons concerned

The use of AGOV does not transfer this responsibility to the Federal Chancellery or the authentication service.

11.3 Citizens’ data

E-government applications frequently process personal data relating to citizens. Depending on the business process, this may include sensitive personal data, tax data, health data, social-security data, procedural data or other information with increased protection requirements.

Before processing data on a SaaS or hyperscaler platform, the responsible authority must in particular assess:

  • whether a sufficient legal basis exists
  • which data is required for the relevant purpose
  • the consequences of a breach of confidentiality, integrity, availability or traceability
  • where data, backups, logs and telemetry data are processed
  • the provider’s administrative and technical access possibilities
  • the sub-processors involved
  • possible access from abroad
  • control of cryptographic keys
  • whether data can be fully exported and deleted
  • whether migration to another platform is possible
  • how operations can be maintained in the event of failures, termination of the contract or geopolitical changes

11.4 Digital sovereignty

Digital sovereignty is not a binary state. It refers to the degree of control and ability to act that a public authority requires in the digital environment.

When using a hyperscaler, the following factors must in particular be weighed:

  • legal and technical control
  • dependency on a single provider
  • switching and repatriation capability
  • control over data and cryptographic keys
  • availability of alternatives
  • command of the overall architecture
  • in-house operational and governance expertise
  • contractual enforceability
  • concentration and cascading risks
  • resilience to crises and geopolitical change

An international provider is not excluded solely because it operates internationally. Equally, a solution is not digitally sovereign solely because data is stored in a data centre located in Switzerland.

The decisive factor is the responsible authority’s actual degree of control and ability to act.

11.5 Contribution of AGOV

AGOV can strengthen the digital sovereignty of a cloud architecture by avoiding the need to transfer primary authentication of the natural person entirely to the cloud provider.

This may in particular reduce dependencies on:

  • additional passwords held by the cloud provider
  • proprietary authentication procedures
  • complete transfer of the person’s primary identity to a commercial cloud directory
  • separate identity-verification procedures for individual platforms
  • permanent dependency of public-sector authentication on a single provider ecosystem

The use of AGOV does not, however, remove the other dependencies associated with a cloud platform. Data storage, application logic, administration, permission management, availability and exit capability must continue to be assessed separately.

12. Conclusion

AGOV may be used for locally operated applications, SaaS products and applications running on hyperscaler platforms.

Connections are established directly or through an existing IAM or identity broker using OIDC or SAML.

Product-specific interoperability requirements may be submitted to the Swiss Federal Chancellery through the regular channels. They form part of AGOV product governance and the continued development of the service.

AGOV authenticates the natural person. It does not decide on the permissibility of a cloud platform, the processing of citizens’ data or business access rights.

The responsible authority, or relying party, assesses the legal basis, protection requirements, information security, data protection, digital sovereignty and the necessary technical, organisational and contractual measures.

This enables authentication governed by public authorities to be combined with modern cloud technologies without conflating the responsibilities of AGOV, the relying party and the cloud provider.