> For the complete documentation index, see [llms.txt](https://docs.fortifiedid.se/access/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fortifiedid.se/access/readme/why-access.md).
# Why Access?
Why organizations choose Fortified ID Access and where the product is especially strong.
This page explains why organizations choose Fortified ID Access, what kind of authentication flexibility it supports, and where the platform is especially strong in the Swedish and Nordic identity landscape.
## Why Fortified ID Access?
Fortified ID Access helps organizations centralize login, federation, and identity delivery in one place instead of solving the same problem separately in every application. As an **IdP**, it authenticates the user, decides how the login flow should behave, and delivers the right identity information to the connected application.
This makes it possible to provide **Single Sign-On (SSO)**, apply **Multi-Factor Authentication (MFA)** where needed, support **passwordless authentication**, and control which login methods are available for each connected application. It also makes it possible to use **step-up authentication** for selected applications, for example by requiring additional authentication even in an SSO scenario when a connected service needs a higher assurance level. Because this is handled through configuration rather than custom development, organizations can adapt security and user experience without building separate integrations or plugins for each application.
Overview of Fortified ID Access
Access also supports modern federation roles and standards such as **`SAML`**, **`OIDC`**, and **IdP broker** scenarios. It can act in different roles depending on what the environment requires, including:
* **`SAML` IdP** for standards-based enterprise federation
* **`SAML` broker** for bridging trust between identity domains
* **`OIDC` OpenID Provider** for modern web and API-based applications
* **`OIDC` Relying Party** and other protocol-specific integration scenarios
Another important strength is **authorization** and **identity enrichment**. Authentication is often only one part of the problem. Organizations also need the right claims, roles, and attributes to reach the application in a controlled way. Access can collect identity and authorization data from multiple sources, normalize it, and include the correct information in the outgoing assertion, token, or ticket.
Access also supports **auditing** and **audit trails** for authentication events, which is important for security, traceability, and operational follow-up. This gives organizations the ability to track who signed in, when the sign-in took place, and how the authentication flow was completed.
## Built for flexible authentication
Fortified ID Access is built for organizations that need freedom of choice in how users authenticate. Different applications, user groups, and assurance levels often require different login experiences, and Access makes that manageable through **simple configuration**.
This means the organization can:
* Offer different authentication methods for different connected applications
* Combine methods into stronger login flows when risk or policy requires it
* Move from passwords to **passwordless** journeys where appropriate
* Adjust login choices over time without redesigning the whole federation setup
The platform supports a broad set of authentication methods so customers can choose what fits their users, security posture, and regulatory environment.
## Strong in the Swedish and Nordic market
Fortified ID is a **Swedish company** with a strong focus on the **Swedish market** and the **Nordic market**, and Fortified ID Access is designed to support the identity methods and federation patterns that are especially important in Sweden and across the Nordics.
This includes support for well-known Nordic authentication methods and identity ecosystems such as:
* **Swedish BankID**
* **Norwegian BankID**
* **Finnish BankID**
* **Freja eID+**
* **Freja OrgID**
* **SITHS**
* **Swedish federations**
This focus matters in practice. Organizations in Sweden and the Nordics often need an IdP that is not only technically standards-based, but also aligned with national identity methods, public-sector expectations, healthcare requirements, and local federation models. Access is built to meet those needs while still supporting broader enterprise and cross-system integration scenarios.
## Relevant for the Swedish public sector
Fortified ID Access is also well suited for **public-sector organizations in Sweden**, including **government agencies**, **regions**, and **municipalities**. These environments often have identity and login requirements that go beyond standard office scenarios, and Access can help solve several of the practical challenges that follow from that.
Examples include:
* **Shared devices**, where employees do not always have their own dedicated mobile device and need authentication flows that still work in operational environments
* **Self-registration of accounts**, where a user account can be created based on trusted identity data from a successful login with an **electronic identity**
* **Acting on behalf of another person**, where one user logs in with their own identity but is allowed to act in the role or context of another person
These scenarios are important in many public-sector workflows where usability, traceability, and secure identity handling must work together. Access makes it possible to support them within the same IdP platform rather than solving them separately in each application.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.fortifiedid.se/access/readme/why-access.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
