How do Altinn 2 roles map to Altinn 3 access packages?
They do not map one to one. Altinn 3 replaces the Altinn 2 role model with access packages: named bundles of rights with stable urn:altinn:accesspackage:* identifiers, delegated as a unit rather than service by service. Roles from the Enhetsregisteret still matter, but differently: registering an accountant or auditor now pre-assigns the matching packages automatically, and key roles such as the managing director also receive the administrator roles that let them delegate packages onward. Altinn 2, and the roles that existed only inside it, was decommissioned on 19 June 2026.
Why were roles replaced with access packages?
An Altinn 2 role was a bundle too, but a bundle maintained per service by each agency, and delegating one meant reasoning about a list of individual services that grew and shifted underneath you. The package model moves the bundling to a shared catalogue. Digdir's authorization team defines each package, its name and its urn, and groups packages into areas inspired by how businesses are actually organised. Service owners then attach their services to the packages where they belong.
That attachment is the detail worth internalising: a package does not contain a fixed list of services. Its real content is the sum of the authorization rules in which service owners have used it, so when several agencies attach payroll-related services to the same payroll package, the package becomes the shared industry bundle for that area. Granting it grants everything in it, from every agency that participates, which is what makes the grant screen answerable by a finance manager rather than only by a developer.
The retirement itself is behind us. Altinn 2 was decommissioned on 19 June 2026, and the roles that existed only to gate Altinn 2 services were phased out on the same clock. If your integration or your onboarding instructions still reason in terms of those roles, the reasoning now points at a system that no longer answers, which is usually how this question surfaces: something worked in the old model and nobody can say what the equivalent grant is in the new one.
Which packages replace the accountant and auditor roles?
The professional client relationships have the cleanest story, because the registry does the work. When a client registers an accounting firm in the Enhetsregisteret, the accountant packages arise from that registration automatically; the same mechanism covers a registered auditor. There is no delegation screen in the standard case, and the grant follows the registered relationship rather than any person's login.
| Registry relationship | Access packages in Altinn 3 | How the grant arises |
|---|---|---|
| Registered accountant (REGN) | regnskapsforer-med-signeringsrettighet, regnskapsforer-uten-signeringsrettighet and regnskapsforer-lonn, each under urn:altinn:accesspackage. | Automatically, when the client registers the accounting firm in the Enhetsregisteret. Granted only to authorised accountants. |
| Registered auditor (REVI) | ansvarlig-revisor and revisormedarbeider, each under urn:altinn:accesspackage. | Automatically, when the client registers the auditor in the Enhetsregisteret. Granted only to authorised auditors. |
| Key roles such as managing director (DAGL) | The pre-assigned packages for the business, plus the hovedadministrator and tilgangsstyrer roles. | Automatically from the Enhetsregisteret registration. The administrator roles are what let them delegate packages onward. |
| No registered relationship | Whatever the client delegates explicitly, for example the skattegrunnlag package in the documented system user scenarios. | By manual, organisation-level delegation. Nothing arises automatically without a registry entry. |
What changes for API consumers and system users?
Two things, and both simplify over time. First, the unit your system asks for changes: a system registered in the Altinn System Register declares the access packages it needs, and each customer grants those packages to the system user they create for you. Your authority checks then reason about packages held versus packages required, not about role memberships. The mechanics of that grant are owned by the system user delegation guide, which this page deliberately does not restate.
Second, the failure modes change shape. Under the role model, a rejected request usually meant a missing role on a person. Under the package model, the interesting questions are whether the package a service requires has been delegated to your system user, and whether the person who approved your request held the packages they were approving. Most packages carry pre-assigned registry roles that can delegate them; the sensitive ones carry none, and only the business's hovedadministrator can hand those out.
For the service-by-service version of this question, ask the machine rather than a spreadsheet. Apier's zero-auth altinn-migration tool answers per Altinn 2 service code with the Altinn 3 replacement, and every entry carries a verifiedflag stating whether that mapping has been confirmed against authoritative documentation. An unverified row says so on the response, which is the same honesty rule this page's table follows.
Make the first call
Both calls are zero-auth. The first asks what replaces one Altinn 2 service; the second lists the whole map, verified flags included.
# Zero-auth: what replaces one Altinn 2 service.
curl -s "https://www.apier.no/api/v1/tools/altinn-migration?altinn2_code=A0212"// The full migration map, one entry per Altinn 2 service code.
const res = await fetch(
"https://www.apier.no/api/v1/tools/altinn-migration",
);
if (!res.ok) {
// Every non-2xx answers the same structured envelope.
const { error_code, explanation } = await res.json();
throw new Error(`${error_code}: ${explanation.summary}`);
}
const { data } = await res.json();
// Each entry states its Altinn 3 replacement and carries a verified
// flag, so an unconfirmed mapping is visible rather than guessed at.
for (const entry of data.mappings) {
console.log(entry.altinn2_code, entry.verified);
}Frequently asked questions
- Are Altinn 2 roles gone already?
- Altinn 2 was decommissioned on 19 June 2026, and the roles that only existed to grant access to Altinn 2 services are being phased out with it. What remains authoritative is the Enhetsregisteret: registry roles such as accountant, auditor and managing director still exist there, and in Altinn 3 they pre-assign access packages instead of Altinn 2 roles.
- What exactly is an access package?
- A named bundle of rights with a stable urn, defined and maintained by Digdir's authorization team. Service owners attach their services to a package in their authorization rules, so the package's real content is the sum of what every agency has attached to it. Granting the package grants everything in it, across all the agencies that use it.
- Which packages does a registered accountant get?
- Three packages exist for the accountant relationship: accountant with signing right, accountant without signing right, and accountant payroll. The fullmakt arises when the client registers the accounting firm in the Enhetsregisteret, so there is no delegation screen for the standard case. Which of the three applies depends on the registered relationship.
- What if my client has no registered relationship with me?
- Then nothing is pre-assigned, and the client delegates a package by hand. The documented system user scenarios use the skattegrunnlag package this way: a client that has not registered an accountant in the Enhetsregisteret delegates that package at organisation level, and the system user then acts under it. The grant is explicit rather than automatic.
- How do I find the replacement for one specific Altinn 2 service?
- Ask per service rather than per role. Apier's altinn-migration tool answers with the Altinn 3 replacement for a given Altinn 2 service code, zero-auth, and every entry carries a verified flag stating whether the mapping has been confirmed against authoritative documentation, so an unverified mapping is marked rather than silently asserted.