Walk into almost any modern office, hospital, or school and you will see the same thing at the door: a badge reader connected to a networked access control system. What used to be a simple electric strike on a keyed door has turned into a full-blown IT system, talking to servers, cloud platforms, and mobile apps.
The upside is huge. Centralized control, audit trails, integration with a broader security management system, remote management, even touchless entry. The downside is that every one of those benefits leans on connectivity, and connectivity invites attackers.
I work with organizations that only discover the cyber risk of their access control system after a penetration test, an incident, or a near miss. The story is often the same: the system was specified as a physical security project, not an IT one, and the networked parts quietly grew over time.
This article walks through how to think about cybersecurity for networked access control, what tends to go wrong in the field, and how to build something resilient without turning your building into a fortress of unusable doors.
What a modern access control system really is
On paper, a door is simple: a reader, a controller, a lock. In reality, a contemporary access control system usually includes:
Readers and keypads at doors, sometimes with Bluetooth, NFC, or QR support.
Door controllers and I/O modules that talk IP, RS-485, or proprietary protocols.
A server or cloud platform that holds cardholder data, access levels, schedules, and logs.
Client workstations, web consoles, or mobile apps used by security and facilities staff.
Integrations with other parts of the security management system, such as video, alarms, visitor management, or HR databases.
Every one of those components has an attack surface. The moment you plug a controller into the corporate LAN, you have extended your cyber risk envelope out into the ceiling space and security closets.
The key mental shift is to stop treating access control as “just hardware” and see it as a specialized networked application that happens to move locks instead of files.
Why attackers care about doors
If you ask a cyber team to prioritize assets, they usually start with email, ERP, source code, or medical records. Physical security systems are often listed much lower. From an attacker’s perspective, that is a gift.
There are three broad motives for targeting access control.
First, physical entry. Unlocking one critical door, whether in a data center, pharmacy, or executive suite, can make the rest of your cybersecurity irrelevant. If an attacker can badge into the server room, they no longer care how good your MFA is.
Second, pivoting. Many access control servers sit on the same flat VLAN as business applications. The server often runs a legacy OS, outdated web server, and vendor software that is rarely patched because “it controls the doors”. That cocktail creates an almost ideal beachhead for lateral movement.
Third, data. Cardholder databases can reveal staff names, departments, and schedules. Door logs can show work patterns, shift changes, and when high value areas are occupied. Even if an attacker cannot unlock doors remotely, that intelligence has value.
A lot of organizations only appreciate this after they see a red teamer use a neglected access control server to jump into the rest of the network.
Common weak spots visible in the field
When you assess enough facilities, patterns emerge. The specific brands and models change, but the mistakes are familiar.
One frequent issue is flat networks. Controllers, cameras, printers, and random OT devices all sit on the same subnet as office PCs. An infected laptop can see every controller. If the controllers use default credentials or plain text protocols, it is only a matter of time before someone abuses that visibility.
Another recurring problem is weak segmentation between the security management system and the broader IT estate. Security workstations sometimes double as staff PCs, with email and web browsing on the same machine used to administer doors. Phishing that user becomes a direct route into the access platform.
Legacy servers are also a big one. I still see core access control servers on unsupported versions of Windows, sometimes virtualized, sometimes physical, rarely patched. The argument is always the same: “the vendor said we should not patch without their approval” or “a patch broke the system five years ago so we stopped”. That fear leads to technical debt that attackers are happy to exploit.
At the edge, readers and controllers are often treated as “dumb” devices, even when they are not. Installers leave default passwords, expose management ports, or plug controllers into open network jacks that anyone can access from a closet.
None of these issues is exotic. They are ordinary operational shortcuts that gradually add up to systemic risk.
Architectural principles that make a difference
Before diving into specific controls, it helps to adopt a few architectural principles. These are not buzzwords, they are habits of mind that guide decisions when you specify, buy, or deploy access control.
Treat the access control system as a critical application, on par with a financial or clinical system, rather than as miscellaneous building equipment. That means it gets included in risk assessments, change control, backup strategies, and incident response.
Default to least privilege. Doors, controllers, operator accounts, and integrations should all get exactly the rights they need, not whatever is easiest. If the HR feed only needs to add and remove users, it does not need the ability to unlock doors.
Segment aggressively. Access control devices should live in their own network segments, with tightly controlled paths in and out. If someone plugs a rogue laptop into a door controller switch, they should hit a wall of ACLs and firewalls, not a red carpet into your corporate LAN.
Plan for compromise. Assume something will fail at some point. Your job is to design so that a single compromised reader or workstation does not topple the entire system or unlock every door.
Value simplicity. Fancy integrations and convenience features tend to expand the attack surface. If a feature does not deliver clear operational value, consider leaving it unused, even if the vendor advertises it heavily.
With those in mind, we can look at specific technical areas that deserve attention.
Identity, credentials, and card data
Access control starts with identity. Who are you, and what are you allowed to do at this door at this time. The cryptographic strength of that answer matters just as much on a door as it does in a login prompt.
Older card technologies like 125 kHz prox are trivial to clone with commodity hardware that costs far less than a laptop. I have watched attackers copy a badge in a crowded lobby in seconds, then walk to a different entrance and gain entry as if they belonged there.
Moving to more secure credential technologies is one of the highest impact steps you can take. That usually means some combination of modern smartcards with secure key storage, mobile credentials with proper mutual authentication, or biometrics in high risk areas. The specifics depend on your risk profile, but staying on easily cloned media is rarely defensible anymore.
It also pays to think about how card data is stored and transmitted. On the reader-to-controller side, consider OSDP with secure channel rather than unencrypted Wiegand, especially for exterior doors or publicly accessible readers. On the backend, cardholder databases should be encrypted at rest and protected like any other store of personal data.
Authentication policy is another lever. Many sensitive areas do not need to be convenient, they need to be safe. Two factor at the door, such as card plus PIN or card plus biometric, is entirely reasonable for a data center or pharmacy. You would not let someone into your core network with just a username; do not let them into your crown jewel spaces with just a clonable card.
Finally, review your lifecycle for credentials. How quickly do you disable a card when someone leaves or reports a loss. I have seen ex-employees walk straight into old workplaces months after departure because their badge was never removed from the system.
Network segmentation and hardening
From a cyber point of view, the network is where you can make or break the risk profile of your access control system.
At a minimum, it is worth treating access hardware as an OT or IoT segment with strict controls. That typically means a dedicated VLAN or set of VLANs for controllers and readers, fronted by a firewall that exposes only a handful of ports to the application server.
If your organization uses microsegmentation or software defined networking, access devices are prime candidates. Most door controllers need to talk only to one or two servers, perhaps a time source, and sometimes a management interface. Anything beyond that should be questioned.
Commonly, the access control server itself lives in a data center segment rather than in the device VLAN. That gives you the option to wrap it in standard server protections: endpoint security agents, hardened OS baselines, centralized logging, and regular vulnerability scanning. The trick is to do this in concert with the vendor so that you do not accidentally break door operations.
It is also worth looking closely at physical network ports. Many controllers live in intermediate distribution frames or plenum spaces with shared switches. If anyone can unplug a patch cord and connect a laptop, they are now inside your security network. Simple measures like locking network closets, using port security, and monitoring for new MAC addresses go a long way.
The goal is not an airgapped system, which is rarely practical. The goal is a controlled environment where you can reason about all the communication paths and enforce strong boundaries.
Server, software, and patch management
Servers and software are where old habits collide with new realities. Many organizations still treat security management systems as “do not touch” infrastructure. That mindset made sense when these systems were serial islands, but it does real harm when they run on Windows or Linux and sit on IP networks.
The handoff between the integrator, vendor, and IT team matters. Someone needs clear ownership for OS hardening, backup, patching, and performance monitoring. That responsibility cannot float in a gray area between departments.
I often recommend a written support model that spells out who:
Maintains the OS and applies security patches after vendor validation.
Monitors for failed https://lov111vol.com/security-management-system backups and storage issues on the access database.
Manages accounts and roles within the application.
Coordinates upgrades of the application, firmware, and database.
If the answer is “the integrator does everything”, ask hard questions about their security practices. Do they routinely apply security patches once validated. How quickly do they respond to high severity vulnerabilities in their stack. What remote access methods do they use when supporting your system.
For patching, a pragmatic approach helps. Blindly patching production doors every month is a good way to upset operations. Never patching is a good way to impress attackers. Many organizations settle on a quarterly or semi-annual cadence, with emergency out-of-band patches for critical issues, tested first in a non-production environment.
Also, pay attention to the age of the underlying OS. If your vendor still relies on an OS that has gone out of support, you are carrying a long-term liability. Planning migration a year or two ahead is cheaper and less painful than scrambling after an incident forces the issue.
The cloud, remote access, and mobile apps
Access control has followed everything else into the cloud. Hosted controllers, browser-based consoles, mobile credentials, API integrations to HR or visitor platforms: all of it rides over internet paths that you do not directly control.
Proper due diligence on cloud offerings is essential. That means more than checking a marketing sheet for buzzwords. Ask where your data will be stored, how it is encrypted, who has administrative access at the provider, and how they segregate your environment from other customers. In highly regulated sectors, check for regional data residency and compliance attestations that actually match your obligations.
Remote access is another perennial weak spot. Many integrators still want direct VPNs or, worse, exposed remote desktop ports to support systems. From an attacker’s perspective, an RDP endpoint into your security management system is a very attractive target.
If you cannot avoid remote vendor access entirely, treat it like any other high risk administrative connection. Enforce strong authentication, restrict source IP ranges, require jump hosts, and log all sessions. Consider time boxed approvals for vendor access, so they are not sitting with standing administrative privileges 24/7.
Mobile apps and web consoles should go through the same application security review you would apply to any other business software. That includes checking TLS enforcement, session management, logging of administrator actions, and resilience to common web vulnerabilities. If your access control web interface is available from any browser on the corporate network with only a basic password, assume that phishing one operator can compromise it.
Monitoring, logging, and incident response
Door events have always been logged for compliance or investigative purposes. The difference in a cyber context is that those logs now become part of your detection and response strategy.
A mature setup forwards key logs from the access control system into a central SIEM or log platform. That usually includes administrator actions, failed authentication attempts, configuration changes, and unusual door commands. Correlating those with network and identity logs can reveal a compromised operator account or malicious automation.
Think about what “weird” looks like in your environment. An admin account logging in at 3 a.m. from a new IP, unlocking multiple high security doors in short succession, and then changing a schedule is suspicious. So is a sudden wave of failed credential reads at the perimeter, which can indicate someone testing cloned cards.
Integrate the access control system into your incident response plans. If the SOC sees that an employee account is being used in an intrusion, how quickly can you revoke their physical access. If a server is compromised, how do you safely fail over to a backup without leaving doors uncontrolled.
Also rehearse the ugly scenarios. What if you have to fully contain or shut down the access control server during an incident. Do your doors operate in a fail-secure or fail-safe mode. Can you keep critical areas locked while still allowing emergency egress and safety routes. Those are not questions you want to answer for the first time during an active breach.
People, process, and vendor relationships
The human and organizational side often matters just as much as technical controls. Access control tends to sit at the intersection of facilities, physical security, and IT. If those groups only talk during crises, gaps appear.
Clear governance helps. Many organizations create a joint steering group or at least a shared responsibility matrix that spells out decisions on standards, risk appetite, and budgets for the security management system. That body can decide, for example, that no new controller is deployed without being on an approved hardware list and VLAN, or that all operators must use MFA.
Training for access control operators is also often overlooked. These are the people who grant access levels, respond to alarms, and work with vendors. If they fall for phishing or share credentials for convenience, no amount of network segmentation will save you. Teaching them basic cyber hygiene in the context of their actual workflows pays dividends.
Vendor selection and management deserves care too. A low-cost installer that handles access control like an alarm panel may not have the capabilities to support hardened deployments. Ask to see their security policies for remote access, staff background checks, and how they store your configuration backups. When they propose new features, ask how each one changes your attack surface.
In larger environments, it can be worth bringing the access control vendor into routine security reviews. Treat them as a partner in reducing risk, not just a supplier you call when a door fails.
A practical baseline: what “good enough” looks like
Not every organization can rebuild its entire access control system overnight. Budgets, legacy hardware, and operational realities all limit what is possible. Still, there is a pragmatic baseline that most sites can reach over a couple of budget cycles.
Here is a compact checklist that I use when assessing whether a networked access control deployment is reasonably defended:
- Devices and servers live on dedicated, segmented networks, with controlled firewall rules.
- Card technology and reader protocols are updated to avoid trivially cloned or sniffed credentials, at least on high risk doors.
- The access control server is on a supported OS, patched on a regular, agreed schedule, and backed up securely.
- All administrative access, including remote vendor support, uses strong authentication and is logged.
- Key logs from the access control system feed into central monitoring, and incident response playbooks include physical access scenarios.
You can absolutely go further than this, especially in critical infrastructure or regulated sectors, but hitting these points already reduces the low hanging fruit that attackers love.
Planning a phased improvement journey
Treating cybersecurity for access control as a one-off project rarely works. The technology and threat landscape both shift over time. A phased, iterative approach works better and is easier to fund.
A typical journey starts with discovery. Map what you actually have: controllers, firmware versions, networks, integrations, operator roles, vendor relationships. Many organizations are surprised by what they find, such as old controllers still on the network long after a remodel.
Next comes risk assessment. Work with both physical and cyber teams to identify which doors, areas, and functions are truly critical. A back door into the data center or medication vault is not equal to a meeting room. Prioritizing lets you focus limited resources where they matter most.
From there, you can define a target architecture. That might include moving to more secure credentials, segmenting devices, upgrading servers, and tightening administrative controls. Break the work into projects that can align with natural upgrade cycles, building renovations, or lease changes.
Throughout, keep communication flowing with stakeholders. Staff will notice if badge behavior changes, if some doors now require a PIN, or if legacy cards are being retired. Explain the “why” in plain language: protecting data, safeguarding patients, avoiding fines, or complying with contractual requirements.
Finally, bake continuous improvement into your operating model. Review logs for anomalies. Periodically test recovery from backups. Ask your cybersecurity team to include access control in penetration tests. As clumsy as the phrase can sound on a slide deck, “living system” is the right way to think about it.
Networked access control is no longer just about whether a door opens or closes when a card is presented. It is a fully fledged information system that connects people, spaces, and data. Treating it with the same seriousness you apply to your core IT will not only reduce cyber risk, it will make the whole security management system more reliable and trustworthy for the people who depend on it every day.