A test environment held 525,000 records, and 20,000 physical PIN codes

The University of Copenhagen disclosed on October 23 that a cyber-attack had compromised personal data belonging to around 525,000 people. The entry point was a test environment. Two days later the university added a detail that reframes the severity: physical access PIN codes for around 20,000 staff and students had also been compromised.
The distinction between a test environment and a production one is a boundary that security programmes draw for good reasons. Test systems are supposed to hold synthetic data, run older builds and skip the controls that would slow development down. None of those assumptions survive a copy of a real database.

What was in the database

The university's notice describes personally identifiable information including full name, national identity number, work telephone number, home telephone number and personal email addresses. That combination is not a set of contact details. A national identity number plus a name and an address is enough to impersonate someone to a bank, a telecoms provider or a public authority in Denmark.
The PIN codes are the stranger part of the disclosure. A database table of physical access codes is a credential store in everything but name, and it belonged to the same estate. Resetting 20,000 of them is not a password-reset campaign; it requires coordinating with whoever operates the doors, and the university restricted physical access to selected critical locations on campus while it did so.

The timeline

The attack was detected on October 20 and described as brought under control. The public notification followed three days later. On October 23 the university restricted physical access to selected locations and began resetting PIN codes. On October 25 it reported that administrative systems including the document management platform Workzone and the application budgeting tool Nimbus were suffering disruption, and described a preventive and controlled shutdown after a new hacker attack earlier that Monday.
The original notice stated there was no indication that systems supporting day-to-day operations had been accessed or that activities were impacted. The later update describes disruption to two administrative systems. Both statements can be true at the same time, because a preventive shutdown is not an intrusion. The reason the sequence matters is that incident responders rarely get to keep a first assessment unchanged, and organisations that publish one should expect to correct it.
The university said the incident is estimated to fall within the scope of the GDPR, that it has been reported to the Danish Data Protection Agency, and that other authorities are being kept informed. No threat actor had publicly claimed responsibility at the time of reporting.

Why universities keep appearing in this list

Higher education institutions combine decentralised networks, large user populations and a low tolerance for outages. A faculty that cannot log in to a student records system is a visible problem within minutes, which creates pressure to restore service before the scope of an intrusion is understood.
The sector data supports the pattern. A Comparitech study cited in the reporting found ransomware attacks against universities rose 8% between January and June compared with the previous six months, driven mainly by The Gentlemen group. UK government figures published on April 30 found that 98% of higher education institutions had identified a breach or attack in the previous 12 months.
The largest incident of the year in the sector was different in shape: ShinyHunters targeted the Canvas learning management system used by many universities, compromising around 275 million records from over 8,000 institutions. Copenhagen is smaller in record count and more serious per record, because the data supports impersonation rather than just identification.

Controls that would have changed the outcome

Three questions are worth asking of any organisation with a test estate.
Does the test environment contain real personal data, and if so, under what documented decision? A copy of a production database in a test environment converts every protection around production into a protection that now has to be duplicated somewhere with less attention.
Is the test environment in scope for the same monitoring and access control as production? The detection on October 20 suggests some monitoring existed. The three days between detection and notification, and the second attack on the following Monday, suggest the containment was incomplete.
Are physical access codes stored where a database compromise reaches them? A PIN table is a credential table. It should be hashed where the reader allows it, rotated on a schedule, and segmented away from the systems that a web-facing test environment can reach.

The follow-on risk

The data now supports targeted phishing with details that a generic campaign cannot produce: a name, a workplace phone number, a national identity number and a home address. The university's disclosure does not describe any such campaign. The reason to expect one is that impersonation of a public institution is cheap when the caller can recite the recipient's employee number and campus building.
For the 20,000 people whose PIN codes were exposed, the practical advice is separate from the password advice: a code that opens a door is not reset by changing an email password, and the physical security team is the only party that can confirm the reset happened.

References

[1] Infosecurity Magazine, "Copenhagen University Breach Compromises Data on Half a Million People", October 27, 2026. https://www.infosecurity-magazine.com/news/copenhagen-university-data-breach/