Policy-Driven Self-Service Models at Swiss Federal Railways (SBB)

Traditional Identity and Access Management (IAM) often forces organizations to make a painful choice between strict security controls and developer velocity. By shifting to a policy-driven self-service model, Swiss Federal Railways, known in German as Schweizerische Bundesbahnen (SBB) turned this dilemma on its head, proving that automated compliance can strengthen enterprise security while accelerating business processes.

How SBB Is Reshaping Enterprise IAM with Policy-Driven Self-Service

When organizations scale their software development, they inevitably encounter a systemic bottleneck: the traditional IAM queue. In modern multi-cloud environments, development and DevOps teams are accustomed to provisioning heavy infrastructure, such as databases, Kubernetes clusters, and streaming platforms, within minutes via automated self-service portals. However, when they require corporate identity integration, application registrations, or Application Programming Interface (API) permissions, progress grinds to a halt.

Historically, these essential IAM resources have been gated behind manual ticketing systems. Because central security teams are often overloaded, a simple permission request can remain unresolved for days or weeks. This creates an adversarial relationship in which security measures act as sources of friction rather than business enablers.

With the rapid growth of Non-Human Identities, including service accounts, workloads, and machine to machine integrations, this tension has only intensified.  Security teams must maintain strict compliance, but building monolithic "gates" will only lead to teams bypassing security altogether.

SBB is one of Switzerland’s largest employers of custom software developers and operates more than 2,000 heterogeneous applications. We recognized that the traditional model was unsustainable and chose to invert the paradigm. By converting corporate compliance rules into code and embedding identity directly into our enterprise self-service infrastructure, we demonstrated that business velocity and robust security do not have to be mutually exclusive.

This blog outlines the architectural blueprint and the strategic shift in responsibility required to achieve automated governance at scale.

The SBB Architecture Blueprint for Identity Fabrics

To deliver IAM resources safely to developers within minutes, an organization must look beyond individual tools and focus on a cohesive architectural framework. Our approach uses a decoupled, four-tier Identity Fabric architecture that isolates the developer from direct backend configurations while maintaining total control.

Self-Service Architecture

• The Consumer Layer: This is the visible interface, the single pane of glass or central portal through which developers interact with the system. Rather than forcing engineers to visit a standalone IAM silo, all identity and credential request capabilities are natively integrated into our centralized enterprise IT portal alongside standard cloud resources. These capabilities are also fully available through Infrastructure as Code (IaC), allowing developers to manage application registrations through Git repositories.

• The Automation Layer: Acting as the operational engine, this layer leverages GitOps workflows and Continuous Integration and Continuous Delivery (CI/CD) pipelines to handle the actual creation, modification, and provisioning of resources.
• The Policy and Guardrail Layer: This is where core governance occurs. Every automated pipeline must pass through a strict policy engine in which compliance rules, conventions, and security checks are evaluated and enforced.
• The Resource Layer: The final backend tier consists of the underlying source systems that the platform manages, including our core Identity Providers (IdPs), API gateways, and secret management tools.

Crucially, this stack is supported by a cross-cutting capability focused on monitoring, logging, and auditability. Every self-service transaction and underlying policy evaluation is recorded in an immutable or tamper-evident form that supports applicable audit requirements. This helps preserve full traceability even when human intervention is removed from routine provisioning.

Guardrails, Not Gates: Codifying Compliance

The operational foundation to automated IAM is translating high-level, abstract corporate directives (Konzernweisungen) into clear, machine-enforceable policies within the guardrail layer. Instead of expecting a developer to interpret a 50-page security policy document, the self-service interface naturally constrains their actions to a predefined, safe corridor.

For example, when a DevOps team requests a new Single Sign-On (SSO) application registration, our automated policy workflow dynamically enforces several core corporate requirements:

1. Unambiguous Ownership: The system requires each application to be assigned immediately to a designated corporate group, binding the identity to a defined responsibility unit.
2. Lifecycle Management: A definitive lifecycle plan and automated notification channels must be established from day one to support regular recertification or eventual deletion.
3. Least-Privilege Enforcement: Permissions must correspond to defined risk profiles, and time-bound constraints must be applied to elevated access requests.
4. Inventory Integration: The system requires an explicit link to our central Configuration Management Database (CMDB), ensuring data quality and mapping data protection risks appropriately.

By embedding these constraints directly into the graphical user interface and API validation processes, compliance becomes a natural outcome of the developer's normal workflow. Developers remain agile because they receive their credentials instantly, often completely unaware of how tightly the underlying governance framework is guiding their actions.

Inversion of Control: Shifting the Burden of Responsibility

Transitioning from tickets to automation requires more than just technical orchestration. It also demands a cultural and organizational shift known as "Inversion of Control".

In traditional enterprise structures, the central IAM operations team serves as the ultimate arbiter of access. When an application owner submits a ticket for a Microsoft Graph permission, the IAM team must interview the requester, manually verify least privilege, and document the justification. By implementing the change, the IAM team implicitly absorbs the long-term risk of that permission.

Under our new paradigm, we shift responsibility back to the natural business owners who understand the application's actual context. For low- and medium-risk permissions, we provide an expansive self-service catalog integrated with a mandatory, legally binding "Terms of Use" interface.

When developers request access to a specific endpoint, they are presented with explicit constraints regarding purpose limitation, least privilege, and confidentiality obligations. Only after checking "I accept" and documenting a clear business justification does the automation layer provision the permission instantly. The central IAM team ceases to act as a bottleneck. Instead, the application owner assumes direct accountability for the risk introduced to their environment.

We have mirrored this exact strategy across our corporate API Management Platform. Publishing an API, subscribing to data streams, and evaluating consumer access tokens are fully decentralized. The IAM department serves as a platform enablement team, building the secure tooling, designing the guardrails, and facilitating the flow, while the actual business units approve or deny granular requests.

Strategic Prerequisites and the Path Ahead

Achieving an automated, trusted identity ecosystem cannot happen overnight. Organizations looking to move away from legacy gating mechanisms should prioritize four foundational prerequisites:

• Total API Coverage: Every IAM resource intended for automation must be manageable through governed, stable APIs.
• Granular Resource Policies: Comprehensive, standardized authorization models must be mapped out for each resource type before automation of the corresponding resource begins.
• Native IT Integration: Organizations should avoid creating a separate "security portal." True adoption only happens when identity resources are available within the primary enterprise development platform.
• Immutable Traceability: Logging and control monitoring must provide evidence that automated decisions align with applicable compliance requirements.

It is important to be transparent about the implementation maturity. At SBB, our journey is ongoing. Automating most low-risk permissions has significantly reduced the workload of our operations teams, but highly critical resources still require manual workflows. Furthermore, we are actively working toward a unified "Policies as Code" dashboard to provide corporate management with holistic compliance Key Performance Indicators (KPIs).

Ultimately, an enterprise Identity Fabric must not sit in isolation. It serves as the vital connective tissue of the broader enterprise IT Fabric. Aligning IAM directly with overarching corporate IT strategy and business processes ensures higher visibility, smoother audit cycles, and optimal funding. By trusting automation driven by correct, codified policies, security teams can finally scale governance alongside the business, and sleep soundly at night.