Norway's Single Login Became a Single Point of Failure

At about 1 AM on Monday, August 3, someone pointed a DDoS cannon at ID-porten, Norway's national login gateway. By breakfast, Norwegians couldn't sign in to file with the tax authority, check Helsenorge health records, or reach Altinn, the platform businesses use for mandatory government reporting. Digdir's incident page lists ten affected services — ID-porten, MinID, Maskinporten, Altinn, eFormidling, ELMA, eInnsyn, Ansattporten, the contact registry, and the self-service portal. Traffic didn't recover until early afternoon, and then the attack flared up again around 6 PM, dragging instability into the night.

One target. One flood of junk traffic. Most of a country's digital government offline for a working day.

And here's the part that should worry anyone building on public-sector infrastructure: it's the second time in six weeks. On June 20, a DDoS against the network infrastructure of Vivicta — the operations partner that hosts ID-porten for Digdir — knocked the same cluster of services out for roughly 42 hours, from Saturday afternoon until Monday morning. Digdir confirmed no data was compromised in June and notified both the data protection authority and the National Security Authority. Neither attack has been publicly attributed, though Norway has been a recurring target of pro-Russian hacktivist DDoS campaigns since 2022.

The efficiency of attacking the front door

Norway's eID architecture is genuinely good engineering. ID-porten is an OpenID Connect broker: public services integrate once, and citizens authenticate with whichever eID they hold — MinID, BankID, Buypass, Commfides. Maskinporten does the same job for machine-to-machine traffic, issuing short-lived OAuth 2.0 tokens to businesses and agencies calling each other's APIs. Integrate-once federation is why a country of 5.5 million has near-universal digital government while larger nations still mail paper forms.

But federation concentrates risk exactly where an attacker wants it. You don't need to overwhelm the tax authority, the health portal, and the business registry separately — they all outsourced their front door to the same broker, running on the same operator's network. Even BankID, run by the banks, was useless for government logins on Monday, because ID-porten is the intermediary. The attacker's cost-per-service-disrupted approaches zero.

This isn't a Norwegian quirk. The Netherlands' DigiD has absorbed repeated DDoS campaigns over the years, and every country that builds a central eID broker inherits the same chokepoint. What's notable here is the repeat: one successful attack is bad luck; two successful attacks on the same supplier inside six weeks — one lasting 42 hours — says the mitigation capacity behind the contract isn't sized for the threat. A national IdP needs nation-state-grade scrubbing, the kind of always-on upstream absorption that big CDN and DDoS-mitigation providers sell. Digdir's post-June review evidently didn't close that gap, and that's now a procurement question, not just an ops question.

What this looks like from the relying party's side

If you run one of the hundreds of services behind ID-porten — or you're a business integrating with Maskinporten-protected APIs — Monday was a day where your own infrastructure was healthy and your service was still down. That failure mode deserves explicit design, and most relying parties have none. Concrete things worth doing:

• Decouple session lifetime from IdP availability. If your app holds a valid local session, don't force re-authentication on a timer or ping the IdP on every request. Users who logged in before 1 AM should have kept working. Aggressive session revalidation turns an IdP outage into a total outage.
• Treat the token endpoint as unreliable. Maskinporten tokens are short-lived by design, so you can't cache your way through a day-long outage. What you can do is make every submission idempotent, queue outbound work, and retry with exponential backoff and jitter. A thousand integrations hammering a recovering token endpoint in a tight loop are indistinguishable from the attack.
• Ship a degraded mode. Serve cached and unauthenticated content, let users fill forms and save drafts locally, accept uploads into a holding queue. "Login is down" should mean reduced function, not a blank error page.
• Watch the source of truth. Digdir's status page updated every 30–60 minutes through the incident. Wire it into your alerting so your on-call knows within minutes that the problem is upstream — before burning an hour tracing ghosts in their own stack.
• Actually test it. Stub the IdP in staging to return timeouts and 502s, then watch what your app does. Most teams have never run this experiment. Norway just ran it in production, twice, for free.

The uncomfortable direction of travel

The honest editorial call: this changes nothing about whether centralized eID is the right model — it is, and the alternative of every agency rolling its own login is worse on every axis including security. What it changes is the resilience budget. Relying parties have treated the national IdP like DNS: assumed infrastructure, no fallback path, no chaos testing. Two multi-hour outages in six weeks retire that assumption.

It's also a quietly strong argument for the wallet model the EU is pushing under eIDAS 2.0. Device-held credentials that get presented directly to a verifier don't route every authentication through one broker at login time — the central infrastructure matters at issuance, not at 9 AM on a Monday when the whole country needs to log in. That resilience property rarely makes the wallet sales pitch. After this summer in Norway, it should lead it.