Maskinporten has a documented door for non-Norwegian organisations — and a narrower corridor behind it.
A European organisation with an eIDAS electronic seal can request Maskinporten tokens without Norwegian onboarding — but only for scopes each API owner has explicitly opened to European businesses. For everything else, the route runs through Norwegian registration.
The two-sentence background
Maskinporten is the machine-to-machine OAuth2 service operated by Digdir; Norwegian government APIs — Altinn 3, Skatteetaten, NAV and others — accept its access tokens as the organisational identity layer. Everything mechanical about using it (keys, assertions, token exchange, pitfalls) is in the Maskinporten Developer Guide — this page is only about who can get in, from where.
The European eSeals route: real, and narrower than it looks
As of 26 July 2026, Digdir's European eSeals documentation states that a European organisation can obtain Maskinporten tokens by signing a JWT grant with a valid electronic-seal certificate issued by a Trust Service Provider on the EU Trust List — with no Samarbeidsportalen registration at all. On paper that is a genuinely open, eIDAS-anchored door: your existing European seal is the credential.
The corridor behind the door is the scope model. The same documentation states that support for European eSeals is disabled by default and must be activated by the owner of each API, and that only scopes explicitly enabled for European businesses can be used. Digdir publishes a test scope (digdir:verksemd.eu) for the flow, but a test scope grants no production API. The operative question is therefore never “does Maskinporten admit European organisations?” — it does — but “has the owner of my target APIopened its scope to European businesses?” That is a per-API decision you must confirm with the API owner, not a platform default you can rely on.
The standard route: anchored in Norwegian registration
The default onboarding binds a Maskinporten client to your organisation through two Norwegian-registry anchors. The client authenticates with a key or a virksomhetssertifikat — and both issuing CAs anchor that certificate on an entity registered in the Enhetsregisteret. And before production tokens issue, your organisation signs Digdir's bruksvilkår in Samarbeidsportalen; per Digdir's API-consumer guide, production self-service additionally requires ID-porten login and an authorised person for the organisation approving who has access — a step that presumes people who can hold a Norwegian eID. For a foreign business, the entry ticket to this route is the Norwegian organisation number, documented on the Altinn page's NUF section.
What the approval pipeline feels like in practice
One first-hand shape worth pricing in: a scope grant can exist on paper before it works in the portal. In our own onboarding, scopes were formally granted by Digdir on 21 April 2026 — for both the test and production environments — yet the namespace did not appear in the client configuration's scope picker, and a diagnostic follow-up went to the Altinn servicedesk two days later. The general lesson: treat every approval as granted-then-verified, budget a servicedesk round-trip per scope family, and verify a scope end-to-end (token requested, API called) before you declare it done. The cluster hub sequences the applications so this settling time overlaps with your other long-lead steps.
FAQ
- Can a non-Norwegian organisation get Maskinporten access tokens at all?
- Yes, through the documented European eSeals route: a European organisation holding an eIDAS electronic-seal certificate from a Trust Service Provider on the EU Trust List can build a JWT grant, sign it with the eSeal, and exchange it at the token endpoint — with no Samarbeidsportalen onboarding. The catch is on the scope side: it only works for scopes the API owner has explicitly opened to European businesses.
- Which scopes are actually available through the European eSeals route?
- Only the ones each API owner has explicitly enabled for European businesses — support is disabled by default and activated per API. Digdir publishes a test scope (digdir:verksemd.eu) that grants no real API access. Before planning an architecture on this route, confirm with the specific API owner that your target scope is opened to European businesses; do not assume it.
- What is the practical route when the target scope is not open to European businesses?
- The standard route: a Norwegian organisation number (for a foreign business, via NUF registration), a virksomhetssertifikat from Buypass or Commfides, Digdir's bruksvilkår signed in Samarbeidsportalen, and then a Maskinporten client with per-scope applications. That is the sequence the cluster hub lays out in dependency order.
- Where are the actual setup mechanics — JWTs, JWKs, tokens?
- In the Maskinporten Developer Guide, which walks the full flow with working code: certificate, Samarbeidsportalen registration, JWK upload, JWT assertion, token exchange, and the ten pitfalls that each cost a day. This page deliberately covers only the jurisdictional layer above that guide.
Related reading
- Norwegian government APIs for foreign companies — the cluster hub with the full dependency chain.
- Maskinporten Guide for Developers — every mechanical step this page deliberately does not restate.
- Virksomhetssertifikat for foreign entities — the certificate anchor underneath the standard route.
- What a foreign SaaS must do before serving Norwegian customers — the external gates in dependency order.