> 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/common-use-cases/common-use-cases.md). # Common use cases (ENG) Common use cases for Fortified ID Access. This section turns common Fortified ID Access capabilities into practical scenarios you can recognize and reuse. ## Example scenarios [Consolidating data from multiple sources into a token or ticket](#consolidating-data-from-multiple-sources-into-a-token-or-ticket) | [ServiceNow with Swedish eIDs](#servicenow-with-swedish-eids)\ [eID without extra intermediaries](#eid-without-extra-intermediaries) | [Authentication with organization-owned eID](#authentication-with-organization-owned-eid)\ [SITHS authentication with Fortified ID Access](#siths-authentication-with-fortified-id-access) | [Secure identification on shared devices](#secure-identification-on-shared-devices)\ [ADFS with Fortified ID Access](#adfs-with-fortified-id-access) | [Connecting to federations such as Skolfederation, SAMBI, SWAMID, eIDAS, and Feide, as well as services such as DNP](#connecting-to-federations-such-as-skolfederation-sambi-swamid-eidas-and-feide-as-well-as-services-such-as-dnp) | [Tailored sign-in for different municipal target groups](#tailored-sign-in-for-different-municipal-target-groups) | [Introduce passkeys without rebuilding existing solutions](#introduce-passkeys-without-rebuilding-existing-solutions) ### Consolidating data from multiple sources into a token or ticket **Use case**\ Organizations often need to include identity and authorization data from more than one source when a user authenticates. For example, the basic identity can be retrieved from `Active Directory`, enriched with role or business information from a `SQL` database, and then used in a token or ticket that is sent to an application. Another example is to retrieve identity data from `Active Directory` and then enrich it with information from an external web service, such as `Skatteverket Navet/SPAR`, before the right attributes and claims are included in the outgoing identity carrier. By consolidating data during login, organizations can make sure the right information is included without building customer-specific integrations or plugins. **How it maps to Fortified ID**\ Fortified ID `Access` can support this through configurable authentication flows, data collection, and attribute handling where information is retrieved from several sources, normalized, and assembled before it is used in an outgoing token or ticket. With configurable modules, `Pipes`, and exports, data can be processed and reused throughout the flow so that the right values are included in, for example, a `SAML` assertion, an `OIDC` token, or other protocol-carried identity information. This makes it possible to adapt the content of outgoing identity carriers through configuration, for scenarios such as `Active Directory + SQL` or `Active Directory + external web service`, without developing separate plugins. ### ServiceNow with Swedish eIDs **Use case**\ Organizations often need to provide users with secure access to ServiceNow or other line-of-business systems without relying on traditional passwords. By using BankID or Freja eID+ as the sign-in method, organizations can offer a familiar and strong authentication experience that works across many types of operations while reducing the administrative burden of passwords and separate sign-in routines. **How it maps to Fortified ID**\ Fortified ID Access can support this by exposing BankID and Freja eID+ as selectable authentication methods when users sign in to connected applications through, for example, OIDC or SAML. The solution can link the user's electronic identity to an existing account in the organization's directory, such as Active Directory, and then pass the correct identity on to the target platform. This makes it possible to introduce strong sign-in to ServiceNow or other line-of-business systems through standardized integration and configuration rather than customer-specific development. For public-sector organizations, the same pattern can also be complemented with support for SITHS, EFOS, and Freja OrgID, and as a closely related example, Fortified ID also offers IDombud as its own digital identity concept for organizations that want even greater control over the identity lifecycle. ### eID without extra intermediaries **Use case**\ Many organizations already have an established Identity Provider (IdP), but lack built-in support for electronic identities such as BankID. In these situations, they often need to add an external broker service or a separate third-party solution to enable sign-in with an eID. This easily leads to more integrations, more vendors, more agreements, and higher complexity in one of the organization's most critical processes: user sign-in. **How it maps to Fortified ID**\ Fortified ID Access can support authentication with electronic identities such as BankID, Freja, SITHS, and other eID solutions while integrating them into the organization's existing identity environment. This makes it possible to retain control over authentication flows, logging, support, and lifecycle management without depending on a separate third-party eID broker. Fortified ID can also provide connectivity to selected eID providers, such as BankID, giving customers a simpler path to deployment and a single point of contact for technology, support, and agreements. This makes it possible to modernize authentication step by step and simplify the management of critical sign-in flows. ### Authentication with organization-owned eID **Use case**\ Many organizations need strong authentication without relying entirely on national electronic identities such as `BankID` or `Freja eID+`. This becomes especially important when the organization needs full control over issuance, administration, and revocation, or when employees, contractors, partners, or international users cannot be expected to use a personal national eID for work-related access. **How it maps to Fortified ID**\ Fortified ID `Access` can support authentication with organization-owned electronic identities alongside more traditional authentication methods, and can enforce the authentication policies and assurance requirements needed for protected applications and resources. A practical example is `IDombud`, which Fortified ID presents as a digital identity service built around modern wallet-based identity models. This gives organizations a way to combine strong authentication with greater control over the identity lifecycle while keeping the login experience integrated through `Access`. Learn more about `IDombud`: [idombud.se](https://idombud.se/). ### SITHS authentication with Fortified ID Access **Use case**\ SITHS is used by regions, municipalities, private healthcare providers, and public authorities for secure identification, authentication, and electronic signing. At the same time, many organizations need to introduce SITHS into their existing identity environments in a way that is secure, user-friendly, and sustainable over time. **How it maps to Fortified ID**\ Fortified ID Access offers a modern platform for SITHS authentication and can be used both as the organization's primary Identity Provider (IdP) and as a complement to existing identity solutions. Access supports several integration patterns depending on requirements, for example as an IdP or OpenID Provider (OP) with built-in support for SITHS, as a broker or IdP proxy towards Inera, through mTLS-based authentication with client certificates, or in combination with existing platforms such as ADFS. Access can also enrich the identity with information from several data sources, such as HSA, Active Directory, Entra ID, SQL, and other line-of-business systems. This makes it possible to introduce SITHS in the way that best fits the organization, whether the goal is to modernize an existing solution or to consolidate authentication and federation on a common platform. ### Secure identification on shared devices **Use case**\ Shared computers and mobile devices are a common challenge in municipalities, regions, and other environments where several employees use the same equipment during a workday. In healthcare, care services, and schools, this creates high requirements for secure identification and traceability, since multiple people need to use the same device without identities, permissions, or sessions being mixed together. **How it maps to Fortified ID**\ Fortified ID can support this through `IDombud`, where each user has their own personal digital identity protected by a personal `PIN` code. This makes it possible to keep multiple user profiles on the same shared device while ensuring that each profile is protected and only accessible to the user who owns the identity. This gives organizations a way to achieve strong identification, clear traceability, and safer use of shared devices without needing to assign a separate physical device to every user. Learn more about `IDombud`: [idombud.se](https://idombud.se/). ### ADFS with Fortified ID Access **Use case**\ Many organizations still use ADFS as a central part of their identity and access environment. At the same time, the need to support more electronic identities, stronger authentication, and more flexible identity flows is increasing beyond what ADFS alone is designed to handle easily. For many organizations, the question is therefore not only how to replace ADFS, but how to complement the existing solution step by step without creating unnecessary complexity. **How it maps to Fortified ID**\ Fortified ID Access can complement ADFS in several different ways depending on requirements and target architecture. Examples: * **eID layer** - Access can act as an eID and authentication layer on top of ADFS, giving the organization support for, for example, BankID, Freja, SITHS, and EFOS without having to build separate integrations with each provider. * **Stronger authentication** - Access can be used to introduce stronger authentication, such as MFA, or to add support for specific scenarios such as SITHS with ADFS. * **Assurance signaling** - Fortified ID can be used to add assurance signaling to ADFS in scenarios where ADFS participates in a federation with such requirements, for example when connecting to federations such as SWAMID, SAMBI, or Feide. This makes it possible to modernize the identity environment step by step, reduce complexity, and continue using ADFS where it still serves an important role. For further examples, see: * [Microsoft ADFS | Fortified ID](https://www.fortifiedid.se/losningar/adfs) * [On-premise MFA för högskolans ADFS ansluts till SWAMID](https://www.fortifiedid.se/post/on-premise-mfa-f%C3%B6r-h%C3%B6gskolans-adfs-ansluts-till-swamid) * [SITHS eID för Active Directory Federation Services (ADFS)](https://www.fortifiedid.se/post/siths-eid-for-active-directory-federation-services-adfs) * [How to mark primary authentication Fortified ID ADFS adapters as MFA](https://docs.fortifiedid.se/solutions/active-directory-federation-services-adfs/access-policies/how-to-mark-primary-authentication-fortified-id-adfs-adapters-as-mfa) ### Connecting to federations such as Skolfederation, SAMBI, SWAMID, eIDAS, and Feide, as well as services such as DNP **Use case**\ Many organizations use services and applications that rely on federated sign-in through Swedish or European federations. Examples of federations include: * `Skolfederation` for compulsory and upper secondary education. * `SAMBI` for healthcare and care services. * `SWAMID` for higher education. * `eIDAS` for cross-border sign-in between Swedish and non-Swedish services. * `Feide` as a corresponding example in Norway. To connect to such federations, an organization must meet technical requirements related to compatibility, assurance levels, security, and compliance. In addition, individual services may require users to sign in with a method at a specific assurance level. One example is Digitala nationella prov (DNP), where teachers need to sign in with a method at assurance level 3 or higher. **How it maps to Fortified ID**\ Fortified ID Access can be used as a standalone `Identity Provider (IdP)` or as part of one or more federations. As a standalone IdP, Access handles secure authentication for the organization's own applications. Through federations, the same identity can also be used with external services and partners, while the organization keeps control over authentication, security, and user information. In a federation, multiple parties trust common rules for identity, authentication, assurance levels, and attributes. An aggregated federation brings multiple connected parties and services together behind a shared federation model, making it possible for an organization to connect to many services without building separate sign-in solutions for each integration. Fortified ID Access supports connectivity to these federations with high flexibility in authentication methods, assurance signaling, attribute handling, and maintained security and compliance. Access can also handle requirements for stronger sign-in and higher assurance levels, such as LoA3 or LoA4, for services and applications that require them. ### Tailored sign-in for different municipal target groups **Use case**\ A municipality often has many different target groups that need access to different types of services and applications. This may include: * teachers and students who need access to digital services in schools. * care staff who need access to patient records. * citizens who use municipal e-services for matters such as building permits or waste management. * employees who need to sign in to internal systems. These target groups have different conditions and different requirements for identities, authentication methods, and security levels. For example, care staff may need to use an approved method such as SITHS to access patient records, while citizens use an electronic identity to access their own services. **How it maps to Fortified ID**\ With Fortified ID Access, a municipality can handle these needs in a single solution. Access offers multiple authentication methods, support for lookups against different identity sources such as Active Directory, Google, Entra ID, Skatteverket, and HSA, and support for different device types such as PC, Mac, Chromebook, iPhone, and Android. The flexible yet easy-to-use configuration tool makes it possible to create different sign-in flows for different target groups and scenarios. This can, for example, include SITHS sign-in with lookup against HSA for care staff who need access to patient records, or one-time-code sign-in for teachers who need to access a service through Skolfederation. ### Introduce passkeys without rebuilding existing solutions **Use case**\ Many organizations want to introduce a safer and simpler sign-in experience than passwords without creating friction for users or replacing large parts of their current identity environment. Passkeys, based on the FIDO standard, are a strong option because they are phishing-resistant, user-friendly, and can provide a passwordless sign-in experience. In practice, however, it is rarely enough to simply hand out a passkey and consider the job done. Not every application, service, identity platform, and device supports FIDO in the same way, and many organizations already depend on existing federation, SAML, OIDC, directories, onboarding flows, and governing security policies. The challenge is therefore not only to introduce passkeys, but to do so in a way that reuses existing infrastructure and makes the same strong sign-in method available across more services. **How it maps to Fortified ID**\ **Fortified ID Access** handles authentication. Access makes it possible to introduce passkeys step by step and use them as a sign-in method even in environments where not every target application is FIDO-ready. By letting Access act as the authentication layer, the organization can bridge passkeys to existing federation, SAML, OIDC, and other identity flows instead of redesigning every connected service individually. This allows users to get a modern, phishing-resistant sign-in experience while the organization keeps its current integrations, policies, and identity sources. **Fortified ID Enrollment** handles passkey registration. Enrollment supports registration through both self-service and delegated processes. This allows registration to be adapted to the organization’s requirements, for example by protecting it with higher-assurance methods such as SITHS, EFOS, or other electronic identities, or by letting helpdesk, administrators, or other designated roles perform it during onboarding and support. In environments where Microsoft Entra is part of the landscape, Fortified ID can also be used as the controlled workflow layer around passkey activation, giving the organization a more flexible and governed registration process than standard flows alone. This provides several practical advantages: * the same passkey strategy can be used across more applications, not only those with native passkey support * existing integration patterns such as SAML, OIDC, and federation can be reused * enrollment can be protected with higher assurance and adapted to onboarding, support, and recovery processes * the organization can combine self-service and delegated handling depending on user group and risk level * passkeys can be combined with other identity patterns in Fortified ID’s portfolio, such as IDombud and verifiable credentials, in scenarios where identity proofing, onboarding, or future wallet-based flows require stronger control and privacy This makes Fortified ID Access more than support for yet another authentication method. It becomes a way to introduce passkeys without starting over, while preserving the security benefits that make FIDO valuable in the first place, such as phishing resistance, strong binding to the user, and a simpler sign-in experience. For organizations that want to introduce a secure digital identity for sign-in, where the organization owns and issues the identity itself, [Digital Work Identity](/access/readme/digital-work-identity/digital-work-identity.md) can be a relevant next step. It is a solution where passkeys are used as part of the technical foundation for computer-based use. --- # 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/common-use-cases/common-use-cases.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.