By Alen Security’s Dr. Tierney

Is Your Access Control System Secure?

Your access control system connects your doors to software, administrator accounts, and, often, your company network. If you’re responsible for IT across several locations, you need to know who can change that system, how it communicates, and what happens when something stops working.

An access control cybersecurity review should cover system architecture, administrator permissions, network connections, reader security, software updates, remote support, integrations, and recovery. Start by documenting those areas, then confirm that the actual installation meets your company’s requirements.

That gives you something useful to work with when a vendor says the system is secure. You can ask how, see the evidence, and decide what needs attention.

Key takeaways

• Cloud, on-premises, and cellular systems all need defined security controls and clear ownership.
• Administrator accounts deserve close attention because they can change permissions across many doors or locations.
• An encrypted connection to the cloud doesn’t tell you whether communication between the reader and controller is protected.
• Offline operation needs testing, especially when a credential is revoked while a site is disconnected.
• A shared standard makes reviews and support more manageable as you add locations.

Can an access control system create cybersecurity risk?

Yes. Connected physical access control systems can introduce risk through weak administrator accounts, unsupported software, exposed network services, insecure remote support, or integrations with excessive permissions. The level of risk depends on the equipment, configuration, and how people manage it.

Picture an office where the doors work perfectly, but a former service provider still has an active administrator account. Nobody notices a problem during the morning badge check. The account still deserves attention because it may allow someone to change schedules, issue credentials, or remotely open doors.

NIST’s Zero Trust Architecture, SP 800-207, explains that network location or ownership alone should not establish trust. Applied to physical security, that means a controller sitting inside your firewall still needs appropriate authentication, permissions, and maintenance.

You don’t need to assume the system is unsafe. You need enough information to assess it.

Where should an access control cybersecurity review start?

Start with a current architecture diagram and an equipment inventory. Together, they should show what runs at each location, where management happens, and which connections cross into other systems.

For a multi-site business, document the approved design and any locations that operate differently. Otherwise, a review of headquarters can miss the older server still running at an acquired office.

Map the equipment and connections

Ask your integrator to identify the controllers, readers, management platform, servers, databases, and network segments. Include cellular connections, remote support tools, mobile administration, and integrations with identity or video systems.

The diagram should show which way traffic flows and where authentication happens. Pair it with the required ports, protocols, destinations, encryption settings, and supporting services, including DNS and time synchronization.

Record who owns each part

Your inventory should include equipment models, firmware versions, support status, site locations, and the person or team responsible for maintenance. Document where controllers, power supplies, switches, and related cabling are installed, along with who can physically reach them.

This also helps during service calls. Your IT team shouldn’t have to track down the person who remembers which closet contains the panel.

Who should have administrator access?

Give each administrator an individual account, require multi-factor authentication where supported, and limit permissions to their responsibilities. Establish a process for approving access, reviewing it, and removing it when someone leaves or changes roles.

Central management can make a large portfolio easier to support. It also means a broadly privileged account may affect many locations, so those permissions need deliberate limits.

Match permissions to everyday tasks

A site manager may need to issue replacement badges for one office. A regional security manager may need visibility across several locations. Neither automatically needs permission to change integrations or create global administrators.

Separate credential management, door commands, reporting, configuration, and administrator management wherever the platform supports it. Ask the vendor to demonstrate the roles you expect to use.

Include service providers and emergency accounts

Review vendor accounts alongside employee accounts. Confirm who approves them, whether they expire, and how you disable them when a technician or service partner changes.

If you maintain an emergency administrator account, protect it, monitor its use, and document when it may be accessed. A shared password that everyone knows makes it harder to establish who changed the system.

How should access control connect to your network?

Access control network connections should follow documented traffic requirements and your company’s segmentation policy. IT should approve the necessary communication paths and restrict unnecessary access between the security system, the internet, and other business systems.

Ask for the platform’s actual network requirements before installation. A general statement that it “works with your firewall” doesn’t give your team enough information to approve the design.

Confirm inbound and outbound requirements

For a platform designed around outbound encrypted connections, confirm whether any inbound firewall rules or port forwarding are required. Review the specific destinations, protocols, authentication, certificate handling, and update paths.

Avoid unnecessary inbound exposure. Even when a design requires no inbound port forwarding, administrator accounts, device software, and integrations still need review.

Make segmentation enforceable

A dedicated VLAN can help organize access control equipment, but separation also depends on the rules governing traffic between networks. Define which systems can communicate with the controllers and management platform, then confirm those rules are enforced.

Include maintenance access in that conversation. Otherwise, an approved design can gradually change as people add exceptions to solve service problems.

Is cloud access control more secure than on-premises?

Neither architecture is automatically more secure. Cloud and on-premises access control place different responsibilities on your team and the provider, so compare how each proposed system handles identity, updates, data, availability, and recovery.

A cloud platform may reduce local server administration. An on-premises platform may give your team direct control over the server environment. Both need someone accountable for the work that remains.

What to review in a cloud platform

Request the provider’s security documentation and confirm how it handles encryption, software maintenance, backups, incident notification, and service availability. Review data location and sub-processors where your vendor review policy requires them.

Your organization still needs to manage administrator permissions, credential policies, integrations, and local equipment. Confirm which logs you can access and export, including administrative activity.

What to review in an on-premises platform

Identify who maintains the operating system, database, application, and service accounts. Check patching responsibilities, remote administration, backup protection, monitoring, and physical access to the server or appliance.

Ask for evidence of a recovery test. A backup file only becomes useful when your team can restore the system from it.

Does cellular access control avoid the corporate network?

Cellular access control can use a separate connection instead of the local corporate LAN when designed that way. This can simplify deployment at distributed sites, but the devices, management platform, accounts, and support connections still require cybersecurity controls.

The distinction is useful when a location has limited network availability or coordination with local IT would delay installation.

A practical example from retail

In our national retail access control deployment, Alen used Brivo cellular modules to connect locations independently of the retailer’s corporate or store network. The project paired that architecture with centrally managed credentials and regional administration.

That example shows how connectivity can fit the customer’s operating environment.

Check reliability and ownership

Before approving cellular, verify coverage, signal strength, antenna placement, and the effect of the building’s construction. Establish who owns the data plan, who receives connection alerts, and what happens if service is interrupted.

Confirm any connection to other networks or integrations, too. The architecture diagram should reflect the entire installed system.

How do you secure readers and credentials?

Review credential technology and reader-to-controller communication separately. A secure credential needs compatible equipment and sound enrollment practices, while the connection from the reader to the controller needs its own protection.

A statement that “the system is encrypted” should identify exactly which connections it covers.

Verify OSDP Secure Channel

Open Supervised Device Protocol, or OSDP, supports two-way communication between readers and controllers. Its Secure Channel mode encrypts the data exchanged over that connection.

SIA’s February 2026 OSDP implementation checklist recommends enabling Secure Channel and validating that communication works as intended. OSDP support alone doesn’t confirm that Secure Channel is configured and active.

Ask your integrator to confirm reader and controller compatibility, relevant firmware versions, key management, and commissioning test results. Check OSDP Verified status where it forms part of your purchasing requirements.

Plan credential changes around existing equipment

Document which cards, fobs, or mobile credentials you issue, how they’re enrolled, and how lost credentials are revoked. If cloning resistance is a requirement, ask the manufacturer to explain the protections in the proposed technology and configuration.

For a phased upgrade, confirm which existing readers support the new credentials. Your commercial access control design should account for daily use at every affected location, including employees who move between sites.

Who maintains software and controls remote support?

Assign responsibility for updates and vendor access before the system goes live. Each supported component needs an update process, and every remote support connection needs approved authentication, permissions, and logging.

This is easier to settle during planning than during an urgent service call when a location can’t open on time.

Track updates and end of support

Keep a record of firmware and software versions, support dates, and available security advisories. Confirm whether updates happen automatically, require scheduling, or need a technician.

Ask the manufacturer how it receives vulnerability reports and notifies customers. For unsupported equipment, document the exposure, any temporary controls, and a replacement plan with an owner.

Make vendor access visible and revocable

Find out how the integrator connects, whether access stays available between service calls, and whether you can disable it. Require named accounts, appropriate permissions, MFA where supported, and records of support activity.

Keep remote access instructions with your support documentation. The person authorizing a service visit should understand what access they are granting and when it ends.

What should IT check in integrations and logs?

For each integration, document the data exchanged, authentication method, permissions, and failure handling. For logs, confirm which events are captured, how long they remain available, and who reviews alerts.

Connecting access control to an identity system, HR platform, visitor system, or video platform can reduce manual work. It also introduces dependencies your team needs to understand.

Test the employee departure process

Follow an example employee through the full process: the departure is recorded, the integration sends the change, the access control platform processes it, and the affected controllers receive it.

Confirm whether disabling an identity account also removes physical access in your specific configuration. Those actions aren’t automatically equivalent.

Document where integration secrets are stored, how credentials are rotated, and who investigates a failed update. An integration should have only the permissions needed for its task.

Capture changes as well as door events

Access events tell you when credentials were presented. Administrative logs help explain who issued a credential, changed a permission, altered a schedule, or sent a remote door command.

Confirm retention, export options, time synchronization, and compatibility with your monitoring platform if required. Assign an owner to review alerts and respond to unexpected changes or connection failures.

What happens when access control goes offline?

Offline behavior depends on the platform, controller, configuration, and type of outage. Some controllers continue using locally stored permissions and schedules, while new changes or remote commands may not reach them until connectivity returns.

Review loss of internet connectivity, a cloud service interruption, server failure, controller failure, and power loss separately. They don’t necessarily produce the same result.

Test credential changes during an outage

Suppose an employee’s credential is revoked while one location is disconnected. If that controller relies on an older local permission record, the change may not take effect there until communication returns.

Ask how your system handles that situation, how administrators see the disconnected site, and what local response is available. Test new credentials, schedule changes, and event storage as well.

Separate door continuity from platform recovery

Door continuity covers what keeps operating locally. Platform recovery covers restoring management, configuration, records, and failed equipment.

Confirm provider recovery commitments for cloud systems and tested restoration procedures for on-premises systems. Document how a failed controller is replaced and configured. Have qualified personnel verify power-loss and emergency-release behavior as part of the approved door design.

What should a multi-site access control cybersecurity checklist include?

Use one checklist across locations, with evidence and an owner for each requirement. Record exceptions so an older site or unusual connection doesn’t disappear from view after the initial review.

For a manageable first review, take these five steps:

1. Collect the diagram and inventory. Identify missing information and sites that differ from the approved design.
2. Review administrator and support accounts. Confirm ownership, permissions, MFA, and whether each account is still needed.
3. Validate connections and integrations. Compare the installed configuration with the approved requirements.
4. Test failure and recovery scenarios. Include off-boarding during an outage and restoration after equipment failure.
5. Assign corrective work. Record each finding, its priority, its owner, and how you’ll confirm it’s resolved.

Build these requirements into your <a href=”https://alensecurity.com/blog/how-to-standardize-access-control-across-multiple-locations-when-every-site-is-different/” target=”_blank” rel=”noopener noreferrer”>multi-site access control standard</a>. That gives new locations a consistent starting point and makes future changes easier to review.

Frequently asked questions about access control cybersecurity

Does a physical security integrator need to work with IT?

Yes. Connected access control needs coordination between the integrator, IT, and the people responsible for building security. IT should review network connections, administrator identity, integrations, remote support, and maintenance responsibilities. Agree on those requirements before installation so the finished system fits your company’s technology policies and operating needs.

Should access control be on its own VLAN?

A dedicated VLAN may be appropriate when it supports your company’s segmentation design. The security benefit depends on the rules controlling communication between networks, along with authentication and monitoring. Review the platform’s traffic requirements and integrations before deciding how to separate it from other business systems.

Is OSDP always encrypted?

No. OSDP supports encrypted reader-to-controller communication through Secure Channel, but support for OSDP doesn’t confirm that Secure Channel is active. Verify compatibility, configuration, key management, and commissioning results. SIA recommends using Secure Channel to protect the data exchanged between readers and controllers in an OSDP deployment.

Does disabling an employee account immediately disable their badge?

It depends on the integration and whether the affected controllers can receive the change. Disabling a corporate identity account doesn’t prove physical access has been removed. Confirm the integration’s behavior, check synchronization status, and define how your team handles credential revocation at locations that are temporarily offline.

Do older access control systems always need replacement?

No. Age alone doesn’t establish the need to replace an access control system. Review support status, available security controls, integration requirements, and maintenance options. Replacement becomes a stronger consideration when equipment is unsupported or cannot meet your requirements, especially when temporary controls leave gaps your organization cannot accept.

Get clear answers about your access control system

Alen Security works with commercial organizations on access control design, installation, integration, and ongoing service. We can work with your IT and Security teams to review the existing environment and plan a system that fits how your locations operate.

Bring your site list, available system documentation, and the questions your team hasn’t been able to resolve. Whether you’re supporting a New Jersey office or a national portfolio, a clear design and a long-term service relationship make the next decision easier.

Talk with Alen Security about reviewing your access control architecture and IT requirements.

Related reading

• How to Standardize Multi-Site Access Control: Establish consistent requirements for deployment, administration, and support.
• National Retail Client: See how Alen combined cellular connectivity with centrally managed access control.
• Access Control Systems: Explore Alen’s approach to commercial access control and integration.

About Alen Security

Alen Security is a commercial security company based in Cranbury, New Jersey. The company designs, installs, and services access control, video surveillance, and other commercial security systems, including solutions for organizations with multiple locations.