The University of Copenhagen says attackers accessed names, national identity numbers and contact details for about 525,000 people from a test environment, and campus ID card PINs for some 20,000 of those affected were also compromised. A feared second attack on Monday turned out to be a false alarm, but key administrative systems are still offline while the clean-up goes on.
What happened
The University of Copenhagen (UCPH), Denmark’s oldest university with about 36,800 students, detected an intrusion on Tuesday 20 October and went public three days later, on Friday 23 October. According to the university’s own incident page, the attackers got into one of its test environments, not a production system. That test database still held records on roughly 525,000 people, covering full names, Danish CPR identity numbers, private and work telephone numbers and private email addresses.
On Sunday 25 October UCPH added a second disclosure. The PIN codes used with ID cards for around 20,000 staff and students had also been compromised. The university said this was part of the original incident and that it had delayed announcing it until replacement PINs were issued. From the evening of 23 October, entry to a number of sensitive campus sites was limited; they have since reopened.
Then on Monday 26 October UCPH took several administrative systems offline, including the Workzone document management platform and the Nimbus budgeting tool, initially calling it a response to a new attack. By Tuesday it had changed its view. The suspicious activity was not a fresh intrusion, the university said, but activity that had “initially appeared to indicate a new attack”. It added that the precautionary shutdown remains necessary and is linked to the original compromise, so some disruption continues.
Denmark’s data protection regulator has been notified under GDPR. No group has publicly claimed responsibility, and UCPH has not said how the attackers got in.
The detail
The striking point is where the data was sitting. Test environments change constantly, access is looser and monitoring is thinner. Finding half a million real identity records in one suggests the university was testing with production data, or with a copy of it that nobody had masked.
CPR numbers are particularly sensitive, because the Danish civil registration number is the key that unlocks dealings with public services and many private ones. Paired with private phone numbers and personal email addresses, it gives criminals everything they need for convincing impersonation of the university, the tax authority or a bank.
The ID card PINs add a physical dimension: a card plus PIN at the door is only as strong as that second factor, hence the temporary access restrictions.
The Monday scare is also instructive. During recovery, remediation work and attacker remnants can look alike in the logs. UCPH shut systems first and analysed later, a defensible call that shows how hard it is to spot a genuinely new attack mid-incident.
Copenhagen is not an isolated case. According to The Copenhagen Post, DTU and Aarhus University have also been hit in recent weeks, and Denmark’s minister for research, education and digitalisation, Christina Egelund, called in the heads of the country’s eight universities to discuss security.
Why it matters for UK organisations
UK universities share almost every risk factor here: huge user populations, open and decentralised networks, semi-autonomous departments running their own systems, and student record and finance platforms that are tested and upgraded constantly. Infosecurity Magazine cites UK government figures from April showing 98% of higher education institutions had detected a breach or attack within a year.
The legal position is just as demanding. Under UK GDPR, a test system holding real personal data is processing like any other, so the Article 5 data minimisation principle and the Article 32 security duty apply in full. “It was only the test server” will not impress the ICO.
The UK has no direct equivalent of the CPR number, but the National Insurance number, date of birth and home address carry similar weight for fraud. Many UK student record systems hold exactly that mix. And the lesson reaches well beyond universities: any organisation copying production databases into development or test has the same exposure.
UK institutions with Danish exchange partners, or staff who have worked at UCPH, should also expect phishing that uses the incident itself as the hook.
Expert view
In my experience, non-production environments are among the most reliable places to find sensitive data on an internal test. They are built in a hurry, seeded with a production snapshot “just for now”, then forgotten. Access is granted broadly to developers and contractors, MFA is patchy, and logging rarely reaches the SOC.
When we test universities specifically, the problem is multiplied by scale and federation. Central IT may have a sound policy while a faculty team runs its own copy of a student or HR database that nobody centrally knows about.
I would also give UCPH some credit. It published a clear incident page, updated it as facts changed, owned up when its first reading of Monday’s activity proved wrong, and acted quickly on the physical risk from the PINs. The chair of the UCPH Student Council called the three-day wait for an announcement unacceptable, according to Teiss, though that is roughly in line with the 72-hour window for notifying regulators that UK GDPR also uses. The more uncomfortable question is why the data was there in the first place.
What to do now
- Find your copies. Inventory every non-production environment (test, staging, UAT, training, analytics and developer sandboxes) and identify which hold real personal data. Include cloud accounts and shadow systems run by departments.
- Stop using live data in test. Replace production snapshots with synthetic or properly masked data. Where real data is unavoidable, record the justification, minimise the fields and set a deletion date.
- Apply production-grade access control. Enforce MFA, remove shared and stale accounts, and limit access to named individuals. This maps directly to the Cyber Essentials user access control requirement.
- Patch and harden test estates. Test servers are frequently missed by patch cycles and left with default settings. Bring them into scope for Cyber Essentials secure configuration and security update management.
- Log and monitor them. Feed non-production authentication and database activity into your SIEM so that bulk data access raises an alert wherever it happens.
- Review physical access dependencies. If door access relies on card plus PIN, know where PINs are stored, who can read them and how quickly you can reissue them at scale.
- Rehearse the “second attack” moment. Build criteria into incident response playbooks for telling attacker activity apart from recovery noise, and agree in advance who can authorise precautionary shutdowns.
Bottom line
The Copenhagen breach did not need a sophisticated exploit to be serious. It needed real identity data sitting in a place that was easier to reach than production. Every UK organisation that copies live data into test should assume that environment is an attacker’s preferred way in, and either secure it like production or stop putting real people’s data there at all.
Sources
- University of Copenhagen: Operational disruptions at UCPH
- Help Net Security: Cyberattack on University of Copenhagen exposes data of 525,000 people
- Infosecurity Magazine: Copenhagen University Breach Compromises Data on Half a Million People
- The Copenhagen Post: University of Copenhagen hit by second cyberattack days after first
- TechRadar: Over 525,000 hit in massive University of Copenhagen data breach
- Daily Northern: University of Copenhagen says suspected new cyberattack was a false alarm
- Teiss: University of Copenhagen confirms hackers accessed test environment holding data on 525,000 people
