Our SaaS only reads Norwegian company data. Which gates apply to us?

Almost none. Brønnøysund's Tier 1 open data is NLOD-licensed, keyless, and free — a read-only product can ship today with no Norwegian registration, no certificate, and no portal onboarding. The gates on this page exist for products that authenticate as an organisation or act on a customer's behalf.

Which gate should a foreign SaaS start first?

The registry anchor — the Norwegian organisation number — because every other gate references it and it feeds the certificate order, which is itself a verification process measured in weeks. Scope applications go early too: each scope is a separate application with its own review cycle, and a denial can force a re-architecture you want to discover early, not at launch.

Can we clear our customer's delegation gate for them?

No — and that is by design. The per-customer Altinn System User delegation is the legal consent surface: someone with authority at the customer organisation grants your registered system its rights, and they can revoke them at any time. Your side of the gate is making the grant easy (a registered system, clear scope requests, good instructions) — the grant itself is theirs.

Do these gates disappear if we build on an infrastructure layer?

The certificate, portal, and scope gates collapse into the layer's side — that is the point of one — but two things never move: your customer's delegation decision, and your own product's legal posture toward its customers. An infrastructure layer that has already walked the gates removes the sequencing risk; it does not remove the consent surface.

Foreign access

Serving Norwegian customers through government rails: the gates, in order.

A foreign SaaS that wants to read for, file for, or act for Norwegian customers passes a fixed set of gates. Some are yours to clear, one belongs to each customer, and some belong to the platform — and the failure mode is clearing them in the wrong order.

Your gates: identity and access

These are the gates your organisation clears once, in dependency order — the same chain the cluster hub maps in detail. First the Norwegian organisation number (for a foreign business, the NUF registration bridge), then the virksomhetssertifikat issued against it, then Digdir's bruksvilkår in Samarbeidsportalen, then a Maskinporten client in the production environment, and finally the Altinn System Register entry that lets customers delegate to you.

The gate inside these gates is scope approval, and it deserves its own planning line: each scope is a separate application, to the agency that owns the API, with its own review and its own possible outcomes. From our own walk through this pipeline in 2026: one Skatteetaten scope application was denied through the data-sharing track in June 2026 — and the product feature behind it survived by re-routing to Brønnøysund's free Tier 1 data, which carried the same signal without a delegation. Plan scope applications early, expect heterogeneous outcomes across agencies, and keep a fallback data source in the architecture where one exists.

Your customer's gate: the delegation

Once your system is registered, each Norwegian customer must add it as a System User in their own Altinn portal and grant it specific rights — the per-customer delegation described in the Altinn System Users guide. This is the one gate you cannot clear on the customer's behalf, because it is the legal consent surface of the whole model. The practical consequence for a foreign SaaS: your onboarding flow needs a “delegate to us in Altinn” step with instructions good enough for a non-technical administrator, and your runtime needs to treat delegation as revocable state to re-verify, not a one-time setup fact — a System User without rights authenticates but cannot act.

The platform's gates: what you wait on

Some gates sit with the agencies and their infrastructure, not with you: scope reviews take the time they take, granted scopes can need a servicedesk round-trip before they work in practice, and an intermediary you build on may hold binding execution behind its own capability flag until its production access is complete. The going-live guide shows how Apier exposes exactly this as a machine-readable signal — execute_supported on the capabilities endpoint — so client code can poll the platform gate instead of assuming it. Whatever stack you choose, make the platform gates observable in code rather than remembered in a document.

The checklist, condensed

Decide read versus act — a read-only product needs none of the below.
Establish the Norwegian organisation number (NUF for a foreign business).
Order the virksomhetssertifikat (soft variant for servers); calendar the annual renewal.
Sign bruksvilkår in Samarbeidsportalen for the registered entity.
Create the Maskinporten production client and file every scope application early — one per scope, with fallbacks planned.
Register in the Altinn System Register so customers can delegate.
Build the customer-delegation step into onboarding, and re-verify delegations at runtime.
Poll the platform gates in code (capability flags, readiness probes) before the first binding call.

FAQ

Our SaaS only reads Norwegian company data. Which gates apply to us?: Almost none. Brønnøysund's Tier 1 open data is NLOD-licensed, keyless, and free — a read-only product can ship today with no Norwegian registration, no certificate, and no portal onboarding. The gates on this page exist for products that authenticate as an organisation or act on a customer's behalf.
Which gate should a foreign SaaS start first?: The registry anchor — the Norwegian organisation number — because every other gate references it and it feeds the certificate order, which is itself a verification process measured in weeks. Scope applications go early too: each scope is a separate application with its own review cycle, and a denial can force a re-architecture you want to discover early, not at launch.
Can we clear our customer's delegation gate for them?: No — and that is by design. The per-customer Altinn System User delegation is the legal consent surface: someone with authority at the customer organisation grants your registered system its rights, and they can revoke them at any time. Your side of the gate is making the grant easy (a registered system, clear scope requests, good instructions) — the grant itself is theirs.
Do these gates disappear if we build on an infrastructure layer?: The certificate, portal, and scope gates collapse into the layer's side — that is the point of one — but two things never move: your customer's delegation decision, and your own product's legal posture toward its customers. An infrastructure layer that has already walked the gates removes the sequencing risk; it does not remove the consent surface.