Why Physical Access Control Belongs in Breach Scope

Physical access control belongs in breach scope because badge systems, door controllers and PIN databases run on the same networks and identity data as everything else, and a compromise of that data opens doors as well as accounts. When an incident exposes ID card PINs, badge records or door controller credentials, the response has to include the buildings. Most incident response plans do not say who handles that, or how fast.

What is a physical access control system?

A physical access control system (PACS) is the hardware and software that decides who can open which door, and when. It typically includes ID cards or fobs, readers and keypads at each door, door controllers, and a central server that holds cardholder records, access rules and event logs.

Many sites use two factors at sensitive doors: a card the person carries plus a PIN they type. That combination only works if the PINs stay secret. Once they leak, a found, borrowed or cloned card is enough to get through.

What the University of Copenhagen case shows

In October 2026 attackers reached a University of Copenhagen test environment. Alongside personal data for about 525,000 people, PIN codes for the ID cards of about 20,000 staff and students were compromised. Our University of Copenhagen data breach coverage has the timeline.

Two decisions stand out. The university restricted access to selected critical campus locations on the evening it disclosed the breach, after a security assessment. It then waited to announce the PIN compromise until every affected cardholder had a new code, and reopened the locations only after that. Whatever else is still unknown, that sequence treated door access as part of the incident from the start.

Why do IT incident plans miss physical access?

Physical access usually belongs to facilities or corporate security, not IT, so an IT-led investigation may never ask about it. The two teams use different tools, different vendors and often different on-call rotas.

Meanwhile the systems themselves are IT systems. PACS servers run on ordinary operating systems, sync cardholders from the HR or student directory, and send logs to the same network. Test copies of those databases, and exports used for integrations, end up in the same places as other data. Our guide on how to find personal data in test environments includes PINs and badge data in the scan list for that reason.

What should trigger a physical access response?

Treat any of these as a reason to bring facilities into the incident:

• door or alarm PINs, or the hashes they are stored as, appear in compromised data
• the PACS server, its database or a copy of it is in scope
• a directory or HR system that feeds cardholder records is compromised, since an attacker could add or change cardholders
• door controller or reader management credentials are exposed
• card numbers or encoding keys for the card format are exposed, which can enable cloning

Planning the response before you need it

Write the physical access steps into the incident response plan now, while nothing is on fire. Cover four things.

1. Owners and contacts. Name the facilities and security staff who can change access rules at any hour, and the PACS vendor's emergency contact. Put them in the same call tree as IT.
2. Lockdown tiers. Decide in advance which locations get restricted first: data centers and server rooms, labs with hazardous material or sensitive research, cash handling, and network closets. A pre-approved list means nobody debates it during an incident.
3. Bulk reset capability. Confirm that you can issue new PINs to thousands of people in a day or two, and test it. If PINs are assigned centrally, plan how people receive new ones through a channel the attacker cannot read.
4. Compensating controls. While codes are being reset, plan for guards, escort-only access or card-plus-staffed-desk at the restricted doors.

Why should you delay announcing a PIN compromise?

You delay because announcing it before the codes change tells attackers that the PINs they hold still work and invites them to use them. Reset first, confirm the reset reached everyone, then disclose.

That only applies to the specific detail that would help an attacker. Regulators and affected people still need timely notice of the breach itself, and your data protection officer should agree the timing for each item.

Reducing the blast radius

The cheapest physical access incident is the one where little useful data leaks. Practical steps:

• Store PINs as salted hashes where the PACS supports it, never in plain text exports or integration files.
• Keep PACS data out of test environments, or mask it using the methods in our explainer on what data masking is.
• Segment door controllers and PACS servers onto their own network, and restrict which systems can manage them.
• Review cardholder lists against HR and student records every term, and remove anyone who has left.
• Send PACS event logs to the same central logging as IT systems, so investigators can see door events next to logins.

How do you test it?

Run a tabletop exercise where the scenario is a stolen database that contains badge PINs. Time how long it takes to identify the owner of each critical door, restrict it and issue new codes. If the answer is days, that is the gap to close before a real breach finds it.