Your identity provider is not an application: it is infrastructure

Ten Norwegian public services stopped working on Monday. Several of them had nothing wrong with them: the front door of the building had jammed, and it makes no difference how spotless the flats are if you cannot get past the hallway.

At 03:38 on Monday 24 August, Central European time, a denial-of-service attack began against Norway's shared government digital infrastructure: the platform run by the digitalisation agency, Digdir, and Vivicta, the firm that operates it for them. As we write, it has been going for more than two days. It arrived in waves — technicians stabilised the situation on Monday afternoon and it went sideways again that evening — and Digdir's press officer, Are Kvistad, told the NTB news agency it was "two to three times larger" than the previous one. It is the third of the summer: one in late June, another in early August, and this one. Norway's national criminal police, Kripos, has an investigation open into all three.

Ten services affected, by The Record's count. Digdir's bulletins name these: ID-porten, MinID, Maskinporten, Altinn, eInnsyn, eFormidling, ELMA, Ansattporten, the self-service solutions, eSignering and the contact and reservation register. As we write this, the status page update from 01:42 on Wednesday the 26th says ID-porten "still has limitations", with no estimate for restoration. And every statement repeats the same line: no sign of a breach or of personal data being compromised.

The signing service was not attacked: its door had been shut

ID-porten is the single door: where citizens — more than four and a half million of them, according to The Record — identify themselves to enter any public service. And Digdir writes on its status page, in Norwegian and in so many words, what happened to the electronic signing service: "eSignering is unavailable because of the limitations in ID-porten. Signing jobs can still be created, but it is the signing itself that is unavailable".

Read that slowly, because the whole post is in it. There was nothing wrong with the signing service. Its vendors ended up applying their own measures and had it back to normal in the small hours, with ID-porten still limited. An availability incident at the point of identification does not get divided among the services that depend on it: it gets multiplied by them. It is the least intuitive arithmetic in an architecture that is otherwise sound.

There is a second reading in those bulletins that has barely been told outside Norway. At 16:09 on Monday, with the attack still under way, Digdir writes: "The attack is still going on, but the services are stable with the limitations that have been put in place". Part of what was not working had not been knocked over by the attacker. They had switched it off themselves, deliberately, to hold up the rest. That is a degradation plan being executed, and it is the part of the incident that went best.

Single sign-on is still the right call

The easy conclusion would be that centralising identity was a mistake. We do not think so, and saying it here would be cheap: the alternative — every agency with its own login, its own password handling, its own half-built second factor and its own way of offboarding leavers — is worse for security, more awkward to use and considerably more expensive to run. When someone leaves the Norwegian public administration, the deprovisioning happens in one place. That is exactly what centralisation buys, and it is not nothing.

The lesson from Monday is a different one. When you concentrate, the door changes category, and almost nobody does the paperwork that reclassification requires.

What changes when something becomes infrastructure

An application gets bought, installed, patched and backed up. Infrastructure gets sized, routed, degraded in an orderly way and rehearsed. Those are two different repertoires, with two different budgets and two different conversations with the board. The trouble is that the identity provider almost always comes through the first door — just another application in the catalogue, with its per-user licence — and stays there for good, even after years of quietly becoming the thing that decides who works each morning.

For scale: 99.9% annual availability is 8.76 hours of downtime across an entire year. Norway is more than two days in. We do not say that as a reproach — against a sustained attack of this size anyone's number goes — but as the precise measure of why the door deserves a different budget category from the holiday-booking app.

Concretely, treating it as infrastructure means four things you would never demand of an application:

• Its own headroom. Enough for every service that uses it on its worst day, all at once — which is a good deal more than the door moves on a normal one. Sizing it by its own traffic is the original mistake.
• Its own path. If it comes in on the same address, the same link and the same provider as everything else, what you have done is put two labels on one cable. It is the difference between having two links and having two paths.
• A degradation plan. What the services behind it can still do when the door does not answer. Sessions that survive for a while, a break-glass path for a handful of critical accounts, a screen that explains what is happening instead of a generic error. The Norwegians had some of this — which is why you could still create a signing job even if you could not sign it — and it shows. None of it is free, which is why it should be decided calmly rather than at four in the morning.
• Rehearsal. Switching it off on purpose, during office hours, and watching what falls over. It is the only way to find the dependency nobody documented — there are usually three — before it gets found for you by somebody who did not even know you existed.

The last point is the one that meets the most resistance, because it sounds reckless and is precisely the opposite. Breaking your own system deliberately, with people around and the coffee freshly made, is the price of not discovering it in the dark. We do it with timed recovery drills: the last full one took fourteen minutes. That is an internal figure and we offer it as what it is — a test of ours, not a contractual guarantee — but the number only exists because somebody switched something off on purpose on a working morning. The same goes for high availability, which does not prevent an outage so much as shorten it: it is worth as much as the testing somebody has done on it.

The DDoS part is the least of it

On the mechanics of the attack we have little new to add: back in July we wrote, as a network operator, why a firewall will not stop a volumetric DDoS and why RFC 7999 blackholing is not mitigation but orderly surrender. The technical detail is there and it still holds.

DDoS is only one way of jamming the front door, and not even the most common one. The door jams just as well if a certificate expires on a Sunday, if a conditional access rule goes wrong, if your external identity provider has a bad day of its own, or if someone touches a configuration on a Friday afternoon. That last one weighs more than it looks: in a 2003 study of three large internet services, Oppenheimer, Ganapathi and Patterson found operator error — mostly configuration error — to be the leading cause of visible outages in two of the three. And the authors add the caveat that matters here: hardware fails more often, but redundancy masks it. Nothing masks human error. The attacker is one way for the door to jam. We supply all the others ourselves.

The same geometry, two zeros smaller

Change the scale and it is your company. Your directory decides every morning who gets into email, the ERP, the CRM, the shared folder and the VPN. If that directory lives in the same place as everything else, shares the same network path and has no plan for when it stops answering, then you have built the same geometry as Norway with two zeros knocked off.

The version we run into most: a single domain controller, virtualised on the same cluster as everything else, whose backup lives on a server that, in order to restore, needs to authenticate against that same controller. We have already written about that circular dependency and what it costs to undo; the headline is enough here: nobody sees it until the day they need it. The second most common version is the opposite and no better: an impeccable cloud identity provider that fifteen applications depend on, and not one emergency local account anywhere, because "that is insecure". It is. So is being unable to get in and put the fire out.

Three questions that reclassify your door

1. What stops working if your door goes unanswered for six hours? The full list, written down, with application names. It is almost always longer than memory suggests, and there is almost always a surprise: the printer that authenticates against the directory, the time-clock, the customer portal. The long version of this exercise, applied to Microsoft 365, we wrote back in July.
2. How do you get in to fix it? If your administrative access depends on the same door that has jammed, the attacker has achieved something better than taking down a service: they have separated you from your own infrastructure. There has to be a different path, with different credentials, and it has to have been used at least once so you know it works.
3. What is the name of the person who says "we are going to the degraded plan"? A first name and a surname, written down beforehand. Digdir applied deliberate limitations on Monday afternoon and that is what held; somebody signed off on that. In a small company the sign-off ends up falling by default on whoever is on call at five in the morning — the person with the least business context to make it.

All three can be answered in an afternoon and none of them costs a licence. The expensive part arrives the first time somebody asks you them in the middle of an incident.

What does not follow from any of this

That Norway handled it badly, for a start. They published a status page with timestamps, wrote down what they knew and what they did not, and to this day they still have not made up a restoration estimate just to have something to give. That is more than a lot of people manage on an ordinary Tuesday, and from the outside it is very easy to have opinions without the logs in front of you.

And that you need to buy anything. None of the four requirements above is solved by a box, and three of the four are design work and paperwork: mapping dependencies, deciding what gets sacrificed first and writing a name next to that decision. We make a living from this, so take that with the appropriate pinch of salt. But if you finish reading, ask the three questions inside your own company and the answers put your mind at rest, you have gained an afternoon and you owe us nothing.

Sources: start time (03:38 CEST on Monday 24 August), the list of named services, the two verbatim Norwegian quotes — the eSignering one from the 25th at 10:33 and the "stable with the limitations that have been put in place" one from the 24th at 16:09 — and the 26 August 01:42 update with ID-porten still limited and with no estimate — Digdir status page (our translation); the waves and the Are Kvistad quote ("two to three times larger", to the NTB news agency) — The Local Norway, 25 Aug 2026; the count of ten services, Vivicta's role and the 4.5 million-plus ID-porten users — The Record, 25 Aug 2026; the absence of a breach or compromised data — BleepingComputer, 25 Aug 2026; the two-days-plus duration and the Kripos investigation into all three of the summer's attacks — digi.no, 26 Aug 2026 (the exact dates of the two earlier attacks do not agree across sources, which is why no days are given here). Operator error as the leading cause of visible outages in two of the three services studied, and the caveat that hardware fails more often but redundancy masks it — Oppenheimer, Ganapathi and Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?", USITS '03, USENIX. The 8.76 hours a year at 99.9%, the fourteen minutes of our last drill (our own internal figure), reading the single door as infrastructure and the three questions are ours, not the sources'.