Cite this as: Apier.no — Altinn 3 Migration for Developers v1.0

Altinn 3 Migration for Developers

TL;DR. Altinn 2 closes for new role assignments and delegations on June 19, 2026 at 23:59:59 Europe/Oslo. Existing Altinn 2 rights do not migrate automatically to Altinn 3. Every integration that files MVA-melding, A-melding, or any other regulated submission on behalf of a Norwegian company must create Altinn 3 System Users, assign the equivalent access packages, and re-test end-to-end before the cliff. This guide walks the model shift from named roles to scoped access packages, lays out the developer checklist, and embeds a live Altinn 2 code → Altinn 3 access package lookup.

Estimated read time: 9 minutes.

What changes on June 19, 2026

June 19, 2026 is the date Altinn and DigDir have announced as the formal cutoff for Altinn 2's delegation surface. Two operational consequences follow from that single date.

First, Altinn 2 closes for new role assignments and delegations. Any integration that has not migrated its System Users and access packages by that instant cannot mint new delegations against Altinn 2 — there is no Altinn 2 portal left to mint them in. Second, the existing rights granted under Altinn 2 do not silently flow into Altinn 3. The identity layer is technically different: Altinn 3 issues scoped access tokens via Maskinporten and authorises against a resource registry, while Altinn 2 used a named-role model bound to the older portal.

The practical effect for an integration: if you have a production flow that files MVA-melding for a customer today, and that flow relies on an Altinn 2 role like Regnskapsmedarbeider, then on June 20, 2026 that flow stops working. The customer's rights still legally exist — the customer's board still wants their accountant to file VAT — but the technical delegation chain that translated that intent into an Altinn API call has been replaced.

From roles to access packages

Altinn 2 modelled authority as named roles. A person held a role on a company — Daglig leder, Innehaver, Regnskapsmedarbeider, Revisor— and the role carried an implicit bundle of rights to act in specific services. The bundle was opaque: you knew a Regnskapsmedarbeider could file VAT, but the precise grant lived inside Altinn's service-by-service configuration.

Altinn 3 replaces that with access packages: explicit, scoped grants attached to a System User or a personal user. An access package groups related rights — the right to read a company's tax records, the right to submit MVA returns, the right to read NAV's Aa-registeret data — into a named, citable unit. Where the old model said "you are a Regnskapsmedarbeider on this company, infer what that means," the new model says "this System User holds the ‘Skatteforhold for privatpersoner’ access package on this company."

The mapping between the two is N:M. One Altinn 2 role often decomposes into several Altinn 3 access packages (a Regnskapsmedarbeider needs distinct grants for VAT, employer reporting, and tax-account read access). Conversely, a single Altinn 3 access package may cover what previously required two or three different Altinn 2 roles. Plan the migration around the operations your integration performs, not around the role names you remember.

Try it — Altinn 2 role → Altinn 3 access package lookup

Pick an Altinn 2 service code below to see the corresponding Altinn 3 mapping, the migration notes, and the days remaining until the June 19, 2026 cutoff. The data comes from Apier's zero-auth lookup endpoint /api/v1/tools/altinn-migration.

Try it: Altinn 2 code → Altinn 3 access package

Loading roles…

What developers must do

Treat this as a checklist, not advice. Each step blocks the next; skipping is how a working integration on June 18 becomes a 403-storm on June 20.

Inventory current Altinn 2 rights.For each Norwegian company your integration files for, list the Altinn 2 services your code currently calls and the role name the company's signing authority granted. Without this list you cannot size the migration.
Create Altinn 3 System Users. A System User represents your integration acting on behalf of a specific company. The setup runs through Maskinporten plus the Altinn 3 System Register; the apier blog Maskinporten Guide for Developers walks the full setup with code samples.
Assign access packages. For each System User, attach the access package(s) that cover the operations your integration performs. Use the lookup widget above to translate from Altinn 2 service codes — and respect the verified: false flag, which means the mapping is a best-effort reference and must be cross-checked against DigDir before production use.
Test in Altinn 3 sandbox. Submit a real MVA-melding or A-melding against the Altinn 3 test environment with the new System User and the new access package. A passing sandbox submission is not a production guarantee, but a failing one is a hard block.
Verify end-to-end before the cutoff.For each company in your inventory, confirm that a real obligation (the upcoming MVA termin, the next monthly A-melding) flows through the new chain successfully. Do not wait until the week of June 19 — Altinn's support queue compresses sharply in the final days.

Common pitfalls

Assuming roles migrate automatically. They do not. The Altinn 2 → Altinn 3 model shift is a re-delegation, not a data copy.
Over-scoping access packages.The temptation to attach every access package "just in case" defeats the entire point of the new model. Least privilege still applies — and a customer's signing authority can refuse an over-scoped delegation.
Forgetting to rotate System User certificates.The certificate behind the System User has its own lifecycle, independent of the access package grants. A certificate rotation that misses one customer's System User produces an opaque failure on their next filing.
Missing the June 19, 2026 cutoff. Altinn does not offer a grace period. Plan the migration to finish at least two months before the deadline so there is room for unexpected DigDir documentation updates.