Criipto had 22 outages in the last 2 years totaling 79h 22m of downtime — averaging 0.9 incidents per month.
There were 22 Criipto outages since November 17, 2025 totaling 79h 22m of downtime. Each is summarised below — incident details, duration, and resolution information.
Dutch Idin is not available due to an outage at the Idin provider.
The Idin provider has now resolved the issue.
Due to an ongoing breach investigation conducted by the Danish CPR office, all private sector access to address lookups has been temporarily revoked. This is not due to a breach at Idura. See the CPR office status page at https://cprdkprod.statuspage.io/ for more details.
Update on impact: The expected impact is that authentications still succeed and that ID tokens contain no address claims. If you are experiencing a different failure mode, please contact support.
The CPR office reports that private sector address lookup access has been restored. We are monitoring to confirm, but expect that the incident will be resolved soon.
The CPR office has restored access and we have confirmed that address data is now being received again.
Customers are reporting, and we have confirmed, that many requests to BankID are failing. Likely related to the use of scopes
We have identified a workaround for some customers. If you are sending the "phone" scope, you may be able to work around the issue by removing the "phone" scope if you do not need the phone number in your application.
Norwegian BankID reports they have fixed the issue. We have confirmed that the fix works for most customers. We are monitoring for remaining errors.
We have confirmed that the incident has been resolved for all customers.
There are currently issues with signing using Norwegian BankID.
Operations seem to have stabilized. We are monitoring.
This incident has been resolved.
From 14:57 to 15:02 CEST 50% requests for signatures failed, this was due to null-reference exception in proxy handling for criipto.id domains. idura.broker domains were unaffected. From 15:02 CEST to 15:35 about 0.1% requests for signatures failed, due to a sticky load balancer that was not rolled back correctly.
Our main TSA is experiencing performance issues. We have a fallback TSA in place, however, in case of long running/large signature orders, the request might fail. Retrying should work.
The main TSA performance seem to have stabilized. We are continuing to monitor the situation.
Performance has normalized.
We are currently seeing a high error rate for Swedish Address Lookup via SPAR. We are investigating.
The issue appears to be a network-layer/firewall block of requests to SPAR, we are trying to get in contact with SPAR.
SPAR became operational again around 8:00. Exact root cause still unknown.
We are seeing a high error rate from MitID endpoints. This is affecting an increasing number of logins. We are investigating.
MitID error rate is back to normal
We have linked the MitID issues with a combination of appswitch hints and the introduction of MitID CIBA resulting in a parameter combination that MitID rejected. We have added additional telemetry to detect similar issues in the future as well as regression tests against future issues of the same nature.
We have been alerted and are investigating the issue.
Issue only related to the idura.broker domains
Global CloudFront issues. Investigating workaround remediation.
We have located a workaround and are actively working on getting it released.
We are still working on resolving the issue.
AWS is restoring their services to normal behaviour. Our workaround is on the way, but facing a few issues related to duplicate resource naming. We are continuing to prepare the work-around incase it becomes necessary but we are now seeing better error rates from CloudFront, so our mitigation may not be necessary.
Error rate has dropped to 0%, we will continue to monitor
AWS has fixed the issue on their end before we managed to release our mitigation. Our mitigation took longer than initially expected.
A problem with AWS CloudFront Origins resulted in requests towards Signatures were not being able to hit our API.
We are seeing a high error rate for our Signatures product, related to our TSA and QES provider Stø/BankID.
Our underlying TSA provider (Stø/BankID) is still down, which is affecting all signing operations. BankID QES/CSC is still down, which is affecting Norwegian BankID signing operations.
TSA services have been restored - Signing with most eIDs is now working again. Signing with BankID is still down.
Signing with BankID is still down. BankID is investigating the issue.
Issues with the TSA provided by BankID was resolved around 22:15 CEST Issues with Signing provided by BankID was resolved around 05:27 CEST BankID reports that the "The outage in BankID Signing was experienced due to a maintenance."
The provider of Danish addresses ("CPR-kontoret") has acknowledged the problem affecting many of its customers. The are currently working on a fix, with no communicated ETA. Fingers crossed.
The provider of Danish addresses ("CPR-kontoret") reports that the issue has been resolved.
We have reports of users failing to connect to *.criipto.id based domains. We are investigating.
We are continuing to investigate. Multiple network locations are unable to connect to Idura/Criipto domains, while some succeed, and we are still observing succesful logins.
Users report, and Idura staff confirms, that mobile connections appear unaffected. Multiple network locations still fail, likely due to a faulty network location in Azure.
We have reports from customers and our own testing that the network issue is resolved. We will continue to monitor.
This incident has been resolved.
The Verify service powering authentications is currently experiencing issues with an underlying infrastructure components. Service is degraded.
Between 11:30 and 11:39 (Copenhagen time), a system component exhibited intermittent erroneous behavior. 25 logins failed to complete succesfully during the time window. We continue to monitor the behavior closely.
This incident has been resolved.
IN Groupe reports that MitID Web sites and API services might experience instability.
Update from IN Groupe: The MitID Production infrastructure is still experiencing instability. We are working on solving the problem.
Update from IN Groupe: The MitID Production infrastructure is still experiencing instability. We are working on solving the problem. No ETAs provided.
Update from IN Groupe: The MitID Production infrastructure is still experiencing instability. We are working on solving the problem. No ETAs provided.
Update from IN Groupe: Update from IN Groupe: The MitID Production infrastructure is still experiencing instability. We are working on solving the problem. (Same update as previous updates, no new information or ETA)
IN Groupe reports that the incident has been resolved.
The provider of MitID; INGroupe reports that MitID is currently unavailable: https://www.digitaliser.dk/mitid/nyt-fra-mitid/2026/feb/driftsforstyrrelser-mitid
MitID should be operational again: https://www.digitaliser.dk/mitid/nyt-fra-mitid/2026/feb/driftsforstyrrelser-mitid
Signing via the Signatures API is currently available as the underlying TSA service has experienced a service disruption. We are investigating and establishing contact with the TSA provider (Stø / BankID BankAxept)
Issues with connecting to the TSA provider appears to have resolved and signing operations are back to normal.
Message from INGroupe: The MitID Production infrastructure is experiencing instability We are working on solving the problem. Incident: INC0868119 Start: 12.01.2026 @ 09:00 CET
INGroupe reports that the issue is now solved
We are currently seeing an issue connecting to the NemLogin services that power MitID Erhverv and Local IdP. This affects users ability to login with MitID Erhverv, MitID for private citizens is not affected.
NemLogin services appear to have restored, Local IdP and MitID Erhverv are working again.
We have observed issues connecting to Telia who helps power our FTN logins.
Connection issues to Telia have been resolved. FTN is now operational again.
We have received the following details from Telia: > Last night we experienced couple of huge denial of service attacks between > > 2025-11-17 20:31:44 EET à 20:43:10 EET > > and also > > 2025-11-17 23:07:44 EET à 23:15:10 EET. > > Our defensing mechanism has probably been the reason for this outage. I will report this to our DDoS team. Sounds like a IP range whitelisting problem to me. As a future guard against this problem, Telia have now explicitly allow-listed our outbound IP addresses.