For 2 days, millions of Norwegians couldn’t sign a contract, complete a house sale or access a health record because a single supplier’s infrastructure failed for the second time in 5 years.
- BankID, Norway’s e-signing service used by 4.2 million people, suffered its longest outage in 2 decades on 3-4 September 2026, freezing property sales, legal contracts and government services.
- A single vendor, DXC Technology, runs the infrastructure and this was its second multi-day BankID failure in 5 years: textbook third-party concentration risk.
- Norway’s DORA-equivalent law, in force since 1 July 2025, requires firms relying on BankID to assess and report incidents like this to Finanstilsynet (Norway’s financial supervisory authority) fast.
- In a similar American case, the 2024 Change Healthcare attack hit 94% of surveyed hospitals financially via one clearinghouse’s outage.
- GRC teams should test whether “critical” suppliers have actually failed before and build fallback plans now.
What happens when an entire country’s digital ID depends on a single supplier?
On the morning of 3 September 2026, a real estate agent in Norway sat down to close a house sale that had taken months to realize.
It never happened. BankID, the digital identity and e-signing service underpinning almost every legally binding transaction in the country, had gone down, and would not fully recover for 2 days.
As realtor Terje Tinholt of Tinholt Eiendomsmegling (Tinholt Real Estate) told Norway’s largest newspaper Verdens Gang:
“This is a complete crisis. We have 50 to 60 transactions waiting to complete. People are waiting for huge sums of money. We can’t take the money out in cash and deliver it in a suitcase.”
Terje Tinholt,Tinholt Eiendomsmegling
Around 4.2 million Norwegians, almost the entire adult population, rely on BankID to sign contracts, complete mortgage disbursements, give healthcare consent and log into government services. All of that froze at once, not because of a cyberattack, but because a single infrastructure provider’s systems failed.
That’s what makes this story worth attention well beyond Norway: it is a live, real-world test of the third-party concentration risk that regulators from Oslo to Washington have spent the last 2 years writing rules about.
The background: what happened at BankID and why this is a governance story
BankID’s operator, Stø AS, confirmed the outage was the worst in the service’s history. The signing, identity-verification and timestamp services that make a BankID signature legally valid all failed together, freezing property transactions, blocking contract executions across regulated industries and leaving citizens cut off from government digital services.
DXC Technology has run BankID’s infrastructure since October 2021, when the service migrated from its previous provider, Nets. The migration itself overran by more than 3 hours.
5 years on, September’s outage was the second time DXC’s infrastructure caused a multi-day, national-scale failure. For a GRC professional, it is the repetition that’s the headline fact: one failure is an incident, but two from the same vendor in the same critical service inside 5 years is a pattern a third-party risk program should have flagged well before now.
The third-party concentration risk hiding behind “critical” status
Most vendor and supplier risk programs already label providers of services like BankID as “critical.” The gap this outage exposes is what happens after that label is applied. A critical designation is usually assigned once, at onboarding, based on the service a vendor performs, not on continuously tested evidence of how it behaves under pressure. BankID cleared every criticality test on paper long before September: universal, regulated, trusted by government and banks alike. None of that stopped a single vendor’s infrastructure taking the whole system down for 2 days, twice in 5 years.
This is not a uniquely Norwegian problem. In November 2025, the EU’s European Supervisory Authorities designated the first cohort of “critical ICT third-party providers” under DORA, the Digital Operational Resilience Act: 19 firms spanning hyperscale cloud, data center, network and financial-technology infrastructure, now subject to direct regulatory oversight.
As the ESA put it, the goal is “to mitigate risks that could impact the operational resilience of the financial sector of the EU.” Regulators have concluded that concentration in a small number of ICT suppliers is a systemic risk worth direct supervision, not just a line item in a supplier’s file.
In an article covering the EU-UK ICT oversight pact, which seeks to strengthen oversight of critical ICT third-party providers, GRC analyst Michael Rasmussen commented on how DORA and similar legislation around the world reflects the evolution of supplier management. It is, he said:
“A fundamental reframing of third-party risk management; from a procurement and compliance function into an enterprise resilience capability.”
Michael Rasmussen, GRC Analyst & Pundit, GRC 20/20 Research
In another recent news article on supply chain resiliency, Paul Cadwallader, GRC Strategy Director at CoreStream GRC, made the point about critical suppliers more broadly: the label itself is not the safeguard.
“The better question is not ‘How much do we spend with this supplier?’ It is ‘What happens if this supplier cannot perform?’ That shift matters because supplier resilience is about impact, not just procurement value.”
Paul Cadwallader, GRC Strategy Director at CoreStream GRC
BankID was never assessed on spend. It is critical infrastructure with no realistic substitute, but the same principle applies: a criticality label recorded once at onboarding says nothing about whether the supplier behind it can actually withstand a bad day, let alone 2 of them, 5 years apart.
What DORA-grade regulation requires from GRC teams when a critical third party fails
Norway is not an EU member, but it applies DORA through the EEA Agreement, and its own version, the DORA-loven, entered into force on 1 July 2025, 6 months into the Digital Operational Resilience Act timeline in the EU itself. The outage happened well inside the law’s scope: Norwegian banks depending on BankID as a critical ICT third party have direct obligations to identify, test and report disruptions like this one, and Finanstilsynet (the Financial Supervisory Authority of Norway) can impose penalties for non-compliance.
Under DORA Regulation Article 5, that duty sits explicitly with the board: a financial entity’s management body bears “ultimate responsibility” for its ICT risk management framework, including policies on third-party arrangements like BankID (Regulation (EU) 2022/2554, Article 5).
DORA incident reporting is unusually specific for financial regulation. Once an ICT incident is classified as major, an initial notification is due within 4 hours of that classification, and no later than 24 hours after detection. An intermediate report, with preliminary root-cause analysis and updated impact figures, follows within 72 hours. A final report, with confirmed root cause and remediation, is due within 1 month (Regulation (EU) 2022/2554, Chapter III, Articles 17-23).
UK-headquartered firms face a similar logic under the FCA’s operational resilience regime: they must stay within impact tolerance for important business services and evidence that they tested it. The lesson for any GRC team, regardless of jurisdiction, is the same: a critical supplier’s failure is a regulatory event with a clock running from classification, not an operational problem to fix quietly.
Change Healthcare: a US example of concentration risk
Concentration risk is a worldwide problem. In February 2024, Change Healthcare, a US claims clearinghouse processing around 15 billion transactions a year and touching roughly 1 in 3 patient records, was taken offline by a cyberattack. Surveying nearly 1,000 hospitals weeks later, the AHA found:
- 94% reported a financial impact,
- 60% reported a revenue impact of $1 million per day or more, and
- 74% reported a direct effect on patient care.
Parent company UnitedHealth Group disclosed $872 million in direct response and business-disruption costs in Q1 2024 alone, with full-year impacts estimated at $1.15 to $1.35 per share.
The parallel to BankID is close enough to be uncomfortable. Neither company is a household name to the people who depend on it, and both sit invisibly behind everyday transactions: a pharmacy filling a prescription, a homebuyer signing a contract. In both cases, organizations relying on that infrastructure had little ability to switch away from it: the AHA survey found 67% of hospitals said switching clearinghouses was “difficult or very difficult.”
Whether the trigger is a cyberattack in Minnesota or an infrastructure failure in Oslo, the governance failure is the same: a supplier was treated as resilient because it was critical, not because anyone had tested it.
What GRC teams should do now to mitigate against this enterprise risk
There are 4 concrete steps GRC and risk teams can take this quarter to strengthen their third-party risk management framework, without waiting for the next outage.
#1 Audit failure history, not just criticality tier.
Supplier risk management usually starts and ends at onboarding. Instead, pull the list of suppliers already tagged critical, and check which have actually failed before, however briefly. A supplier that failed once and was quietly forgiven is a higher priority than one that simply scores high on a criticality matrix.
#2 Map dependency concentration, not just individual vendors.
The real question is not “is BankID resilient” in isolation, but how many critical processes run through that one provider, and what else depends on the same infrastructure underneath it.
#3 Test regulatory reporting readiness against a real clock.
If DORA, the FCA’s operational resilience rules, or an equivalent regime applies, confirm that the organization could produce an initial notification within hours of a major incident being classified, and that whoever writes it knows the role is theirs beforehand.
#4 Build and rehearse a genuine fallback, not a documented one.
As CoreStream GRC’s own value-based compliance guidance puts it, “if it cannot be evidenced, it did not happen”. A fallback nobody has rehearsed should not be assumed to work.
Conclusion: address concentration risk before it becomes a crisis
That same CoreStream GRC analysis, written in the context of a very different near-miss (a threatened strike by stadium catering staff before the 2026 World Cup) poses the question in its starkest form: “if a critical supplier came under pressure tomorrow, would you know the impact, the owner, the controls, the escalation route and the backup plan?” BankID answers that question in the least comfortable way possible: not hypothetically, but twice, 5 years apart.
The organizations best placed to handle the next version of this will not be the ones with the longest supplier questionnaires. They will be the ones for whom risk and resilience are inseparable: the strategic resilience that comes from already knowing which critical suppliers have failed before, and having tested what happens the next time one does.
If you would like to explore how CoreStream GRC’s third-party risk management capability can move your organization from static questionnaires to continuous, evidence-based monitoring, book a workshop with our GRC Strategy team:
Frequently asked questions about DORA, resilience and the BankID outage
The Digital Operational Resilience Act (DORA) is an EU regulation requiring financial entities to manage ICT and third-party risk, test operational resilience, and report major incidents on strict deadlines. It applies directly only to EU financial entities, but EEA countries such as Norway have adopted equivalent laws, and UK and US organizations operating in the EU/EEA, or supplying EU-regulated financial firms, are affected indirectly through their clients’ obligations. In the US, the Interagency Guidance on Third-Party Relationships: Risk Management, issued jointly by the OCC, the Federal Reserve and the FDIC provides similar guidance (but as supervisory guidance rather than regulation).
Concentration risk is what happens when many organizations, or many critical functions within one organization, depend on the same underlying supplier. A single vendor’s failure can then cascade across an entire sector at once, as BankID’s outage did across Norwegian property, banking and healthcare services simultaneously.
Both involved a single, largely invisible infrastructure provider whose failure paralyzed an entire sector: signing and identity verification in Norway, healthcare claims processing in the US. In both cases, the organizations depending on the provider had little practical ability to switch away from it; the defining feature of concentration risk rather than ordinary vendor risk.
Move beyond onboarding-stage questionnaires to continuous supplier risk management, map how many processes depend on the same underlying vendor, confirm the organization can meet real regulatory reporting deadlines, and rehearse fallback plans rather than merely documenting them.
