- › The access control system records a timestamped, named, high-confidence claim about where a person physically was, and it almost never reaches the SIEM.
- › Badge events turn several expensive detection problems into simple ones, starting with a login from a person whose body is in another state.
- › The barrier is organizational, since the badge system belongs to facilities and the SIEM belongs to security, and the two have different vendors and no shared project.
- › Start with a one-way export of door events to the SIEM and three correlation rules, which is a week of work and not a program.
- › Handle the privacy question directly and in writing, because badge data is employee location data and deserves a stated retention period and a defined use.
Your access control system produced somewhere between four and forty events per employee yesterday. Each one has a name attached, a door, a timestamp accurate to the second, and a physical action that required a person to be standing in a specific place holding a specific credential.
That is a better identity signal than almost anything in your SIEM. An IP address is a guess about location, a user agent is a claim the client makes about itself, and a successful authentication only tells you somebody had the credential. A badge read at the north stairwell at 7:42 says a body was at that door.
In most organizations that data goes into a system run by facilities, gets retained for ninety days because that is the default, and is looked at exactly once, after an incident, when somebody asks whether the guy was in the building.
What the Signal Actually Buys You
We have written about the business case for unifying cyber and physical operations and about what happens when the two teams watch separate screens. This is the smallest and most concrete version of that argument, because it needs no reorganization, no new headcount, and no budget line beyond a log feed. Here is what arrives once that feed exists.
Impossible travel that is actually impossible. The cloud version of this detection compares two IP geolocations and produces a wall of false positives from VPN exits and mobile carriers. Compare a badge-in at your Phoenix office at 8:04 against a successful VPN authentication from a residential block in another country at 8:11, and there is no interpretation problem left. One of those two events involved a physical human being.
Off-hours access with nobody in the building. An administrator account touching a file server at 2:15 in the morning is a maybe. The same event with zero badge activity in the building for eleven hours is a different conversation, and it is the conversation that starts at 2:20 instead of at the next morning’s review.
Terminated employees who still have a working credential. Offboarding failures show up in both systems, and they rarely fail in both at once. A badge that still opens the loading dock two weeks after the account was disabled tells you your two termination processes are not connected, which is a finding you can act on before it becomes an incident.
Tailgating that shows as an accounting mismatch. A person who badges in but never badges out, or a floor with nine badge-ins and fourteen people on it, is not something a camera review will surface efficiently. It is arithmetic, and arithmetic is what a SIEM is good at.
Credential cloning with a physical tell. When the same badge number opens two doors ninety seconds apart on opposite sides of a campus, you are looking at a duplicated credential. We covered how that cloning actually works and the detection for it has always been correlation rather than better card stock.
None of these are exotic. Every one of them is a query somebody could write this month, and the only reason they are not running is that the data lives in a building nobody in the SOC has an account for.
Why It Has Not Happened Already
The reason is organizational, and treating it as a technical problem is how these efforts lose six months to a vendor evaluation nobody needed. The integration work is real but small, and it is not what has been holding this up.
The access control platform belongs to facilities or to physical security. It was bought on a different cycle, from a different vendor, through a different procurement process, and it is administered by somebody whose performance is measured on whether doors work. The SIEM belongs to information security. Neither team has a project that spans the boundary, and neither one has ever been asked to.
There is a technical wrinkle underneath that, which is that many access control platforms were never designed to export anything. Some will write a CSV on a schedule. Some have a database you can query directly if you ask the vendor nicely and pay for the privilege. A few modern ones speak syslog or have a real API. The ones running on a Windows box in a closet with an unsupported operating system are the same ones we described when we argued that your camera vendor is now a network vendor, and getting a log feed out of them is genuinely a project.
But the wrinkle is not the blocker. The blocker is that no single person’s job description contains the sentence “make sure door events reach the SIEM,” so it stays in the category of good ideas that everybody agrees with in a meeting.
The Version You Can Actually Ship
Skip the platform consolidation and skip the joint operations center. Both are real goals worth having on a multi-year plan, and neither one is this quarter, and waiting for either is how the useful version never gets built.
Get a one-way export running
You need door events flowing in one direction into the SIEM, with nothing flowing back. One way keeps the security posture simple, since the SIEM gains a read-only feed and the access control system gains no new exposure. Depending on the platform, this is a syslog forwarder, a scheduled database export, or in the worst case a scripted pull of a CSV drop.
Ask for four fields to start: credential holder identity, door or reader identifier, timestamp, and result. Everything beyond those four is worth having and none of it is required, because those four fields carry every detection described above.
Solve the identity mapping once
The badge system knows Christopher Armour, employee 4471, and Active Directory knows carmour. Nothing in either platform connects those two strings, and every correlation described above is worthless until something does.
The mapping usually already exists inside HR, since both systems were provisioned from the same personnel record at hire. Get that export, build a lookup table, and put the ownership of keeping it current on whoever runs joiner-mover-leaver. This step is where these projects stall, and it is worth doing carefully because every rule downstream depends on it. Our guidance on what to fix first in identity and access applies directly, since a badge identity is an identity like any other and belongs in the same lifecycle.
Write three rules, not thirty
Start with remote authentication while badged on site, privileged account activity with no corresponding building presence, and active badge credential belonging to a disabled account. Run them in monitoring mode for a month and tune out the legitimate patterns, which will be more numerous than you expect. Night shift, contractors, the facilities team, and anybody who works from a car in the parking lot will all generate honest noise.
The rules that survive tuning are worth alerting on. The ones that do not survive were telling you something true about how your organization actually works, which is its own useful output.
Say what you are doing with it, in writing
Badge data is employee location data, and treating it as ordinary telemetry is how a reasonable security control becomes an employee relations problem. Write down the retention period, the specific detections it feeds, who can query it, and what it will never be used for. Attendance monitoring is the obvious thing to exclude, and excluding it explicitly is worth more than excluding it quietly.
Bring this to legal and to whoever owns employee communications before the feed goes live rather than after somebody notices. The organizations that get this wrong are the ones that build it in silence and then have to defend it in a meeting they did not schedule.
What It Will Not Tell You
Two honest limits are worth stating before somebody oversells this internally, because both of them will show up during tuning and it is better to name them at the start than to discover them in a review.
The first is that badge data proves a credential was presented and never proves who presented it. A cloned card, a borrowed one, or a door held open by a colleague all produce a clean record with somebody’s name on it. That is precisely why the correlation is valuable, since the mismatch between the physical claim and the digital one is the thing that surfaces the problem, but a badge event on its own is evidence of a credential and not of a person.
The second is that coverage is uneven in ways that will bite you during tuning. Interior doors are frequently unbadged, some sites have a reader on the way in and nothing on the way out, and anybody who works remotely three days a week generates a presence record that is silent most of the week. A rule written against the assumption of complete coverage will fire on the gaps rather than on the anomalies. Map which of your sites and doors actually produce events before you write anything that depends on absence.
The Part Worth Saying to a CISO
The strongest argument for this work is that the data already exists, is already being collected, is already being paid for, and is already retained. Nobody has to buy anything or ask an employee to do something new. The entire cost is a log feed, an identity mapping, and a few weeks of tuning.
That is an unusually good trade in a field where most detection improvements arrive with a license fee attached. It also produces the kind of finding that is difficult to argue with in a board meeting, since a login from a person whose badge shows them sitting in the building is a specific event with a name and a timestamp on it, and it survives the kind of scrutiny a risk score or a maturity rating never does.
If you want an outside look at what your access control platform can export and what your SIEM could do with it, contact Grab The Axe. You can also take our free Human Attack Surface Score to see where the people-shaped gaps sit.
Chris Armour is Director of Information Security at Grab The Axe.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
