BankID or Freja in Your Login?

When a service needs to know for certain who the user is, the choice often lands on Swedish e-ID. BankID is the obvious name, but Freja exists as an alternative and is getting more attention as requirements tighten and the debate over a state e-ID continues. The question is which one to build in – and whether the answer might be both.

Reach: BankID’s big advantage

The most decisive difference is adoption. BankID has near-total coverage among Swedes and is supported by essentially all banks and a large share of the country’s digital services. That makes it a de facto standard: the vast majority of your users already have BankID and know exactly how it works.

For a service that wants broad reach, that’s a heavy argument. The more people who already have and recognize the verification method, the fewer who get stuck at login. If you only choose one e-ID, BankID is almost always the one that reaches the most people.

Freja is considerably smaller but growing. Its value lies not in matching BankID’s reach, but in complementing it – among other things by being able to reach people who, for various reasons, lack BankID. Where BankID is about breadth, Freja is more about inclusion and specific contexts.

Freja’s special standing with government agencies

What makes Freja interesting beyond being an alternative is its standing in the public sector. Freja has government approval at a level that makes it usable for identification with public agencies. That gives it a special standing in government-adjacent contexts that’s relevant for services that need to meet requirements for a state-trusted e-ID.

For a service that operates close to the public sector, or that might become subject to tighter requirements, that’s a property worth weighing in. The discussion about a future state e-ID also keeps this area in flux, and readiness can be worth something in itself.

Cost and contracts

In practical terms, both are set up as contracts with their respective vendor, and pricing is usually per transaction – per identification or signature performed in the service. The exact terms differ and depend on volume and usage.

That means the cost is best assessed based on how many identifications your service actually performs, not on a list price. A service with occasional logins and one with constant verification get different calculations. If you support both, you get two contracts and two integrations to build and maintain, which is a cost to weigh against the gains in reach and readiness.

The strategy: support both

For many services, the wisest approach is to support both BankID and Freja. There are two reasons.

The first is inclusion and reach. BankID reaches the vast majority, but Freja can catch those who lack it. Offering both means fewer users are locked out for not having the right ID.

The second is readiness. With tighter identification requirements and an ongoing debate about a state e-ID, it’s valuable not to be entirely dependent on a single vendor. Already supporting Freja makes the service more resilient to change and reduces the risk that a future regulatory change forces a rushed rebuild.

A reasonable way to proceed:

1. Start with BankID. Greatest reach, least friction for most users.
2. Add Freja when you want to reach more people, operate in government-adjacent contexts, or want readiness for new requirements.

The cost of supporting both should of course be weighed against the benefit, and for a simple service with a broad general audience, BankID alone can be enough. But for anything sensitive to someone being unable to verify their identity, or that touches the public sector, dual support is often worth it.

At Weapp we build login and signing with both BankID and Freja and help you choose the right level for your service. Check out our services or get in touch, and we’ll go through your requirements.