Which credential do I need: virksomhetssertifikat, virksomhetsbruker, systembruker, or a Maskinporten client?

What does each credential actually let you do?

A Maskinporten client is your organisation's machine identity. You register it yourself, it authenticates by signing a short-lived JWT with a registered key, and the tokens it receives carry the scopes agencies have granted to your organisation. What it cannot do is act for anyone else on its own: a client alone asserts your identity, so data an agency ties to another organisation's consent stays out of reach however many scopes you hold.

The systembruker fills exactly that gap. It is created for a customer organisation and delegated by someone with authority there, and the tokens your client then requests through Maskinporten identify the system user acting for that customer. It cannot widen your own scopes, and it does not exist until the customer grants it, which is a feature: the authority on the call is the customer's, given deliberately, and revocable by them.

The virksomhetsbruker solved the same problem a platform generation earlier: an enterprise user for Altinn 2, signing in with a username and password paired with a virksomhetssertifikat. It still runs in integrations that predate Altinn 3, and that is the only situation that requires it. The certificate itself, finally, is not an access credential but the organisation-issued key that signs Maskinporten assertions, and even that role is no longer exclusive, as the next sections cover.

What is current and what is being retired?

The current model is the Maskinporten client plus, when you act for customers, the systembruker. Both are documented as the standing mechanism: the client authenticates with a signed JWT grant and nothing else, and the system user is the Altinn 3 construct for machine access under an organisation's authority. Nothing about either is transitional, and new integrations should assume them.

The virksomhetsbruker is the one to plan away from. It belongs to Altinn 2, whose shutdown has been announced, and the transition is dated where it touches rights: Skatteetaten's guidance documents Altinn 2 roles and delegation of roles being removed at the start of 2027, with old grants working through a transition window before that. An integration authenticating as an enterprise user today still works against the remaining Altinn 2 surfaces, and every one of those surfaces has a migration date somewhere on it.

The certificate's status is subtler: not retired, but no longer the only option. Maskinporten documents two ways to hold a client's signing key, anchored on a virksomhetssertifikat from Buypass or Commfides, or registered directly as your own key set, which the documentation frames as the way to avoid distributing certificates. The choice affects how you store and rotate the key, not what the client may do.

How do the pieces combine in a real integration?

They stack rather than compete. A vendor serving accounting customers ends up with one Maskinporten client, anchored on one key, requesting tokens that act through one systembruker per customer. The client is yours, the delegations are your customers', and the key is the quiet layer underneath. The confusing question “which one do I need” usually resolves to “all of the current ones, each doing its own job”.

The mechanics of each layer are owned by their own pages: the certificate, assertion and caching detail by the authentication guide, and the question of which token a given Altinn 3 surface wants, Maskinporten's own or the exchanged Altinn token, by the token exchange guide. This page stays the map; those pages are the territory.

Through a broker, the stack collapses from your side. Apier holds the client, the keys and the token loop, and brokers the systembruker flow, so your application authenticates with one Bearer key against one API. What remains yours is the decision no intermediary can make: each customer granting, and being able to withdraw, authority over its own affairs.

Make the first call

The first request needs no credential at all and lists what one Apier key unlocks. The second reads a company's registered signing authority over the brokered surface, with none of the four constructs above appearing in your stack.

# Zero-auth: what one Apier key unlocks, including the scope vocabulary.
curl -s https://www.apier.no/api/v1/capabilities

// Brokered: registered signing authority for a company, no certificate,
// no client registration and no government credential in your stack.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/authority",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

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();
// "sole" | "joint" | "by_role" | "prokura_only" | "no_authority"
// | "unknown", plus the holders.
console.log(data.classification, data.signaturrett_holders);

Frequently asked questions

What is the difference between a Maskinporten client and a systembruker?

Whose authority the call carries. A Maskinporten client is registered by your own organisation and the tokens it obtains assert your identity and your granted scopes. A systembruker is created for a customer organisation and delegated by that customer, so calls made under it act on the customer's behalf. An integration serving many customers typically holds one client and acts through one systembruker per customer.

Is a virksomhetsbruker the same thing as a systembruker?

No. A virksomhetsbruker is an Altinn 2 construct: an enterprise user that authenticates with a username and password together with a virksomhetssertifikat against the Altinn 2 API. The systembruker is the Altinn 3 mechanism for machine access under an organisation's authority, with tokens requested through Maskinporten. New integrations should not be built on virksomhetsbruker.

Do I still need a virksomhetssertifikat for Maskinporten?

Not necessarily. Maskinporten documents two ways to hold the signing key: anchor it on an enterprise certificate, or register your own key set directly with the client, which the documentation describes as the way to avoid distributing certificates. Either way the client authenticates with a signed JWT; there is no client secret variant at all.

Which of these credentials is being retired?

The virksomhetsbruker, together with the platform it belongs to. Altinn 2's shutdown has been announced, and Skatteetaten's guidance documents that roles and delegation of roles in Altinn 2 are removed at the start of 2027, after a transition window. The Maskinporten client, the systembruker and the key underneath them are the current model.

What does Apier hold for me in this picture?

The whole left side of the decision. Apier holds the Maskinporten client, the certificate-anchored keys and the token lifecycle, and brokers the systembruker flow per customer. Your application authenticates with one Apier API key, and the only leg that remains yours is the one no broker can take: your customer granting authority over its own affairs.