On September 24, 2026, Gallagher Security announced that Command Center now supports ASSA ABLOY IN120 Wi-Fi and IN220 PoE intelligent locks. The locks connect to an organization's on-premises IP network without requiring a separate field door controller. Command Center continues to serve as the central environment for managing privileges, credentials, schedules, overrides, events, alarms, audit information, and device health.
The locks themselves are not new, nor is the broader architecture. ASSA ABLOY IP locks have already been integrated with other enterprise access-control platforms. What’s new is the option within the Gallagher ecosystem, making the integration a useful architectural case study: when the reader, locking hardware, network interface, local credential database, and access-decision logic are all concentrated at the opening, responsibilities once handled behind the access-control panel begin shifting onto the network.
That doesn’t make the controller obsolete. Gallagher continues to develop controller-based systems, including its Controller 7000 family. The integration simply gives designers another topology to choose from, changing where they must engineer power, communications, failure handling, endpoint security, and operational ownership.
The access decision no longer has to live in a field controller
A conventional Gallagher-controlled opening typically places the local access decision in a field controller. Readers and I/O devices connect to the controller over interfaces such as HBUS, OSDP, or Wiegand, while the controller communicates with Command Center over the IP network. The server distributes policy and configuration, but the controller retains enough local information to keep making access decisions if its server connection is unavailable.
The IN-series integration redistributes some of these functions. The lock combines the reader, locking mechanism, local decision logic, event storage, network interface and, depending on the hardware configuration, request-to-exit and door-position functions. Gallagher says this approach requires no separate field door controller, placing much more intelligence inside the opening itself.
Command Center still manages enterprise policy and configuration. What has changed is the location of the door-level intelligence beneath it. Rather than a reader reporting to a separate controller that operates the lock, the networked lock can house much of that chain in a single assembly.
There is an important documentation boundary here: Gallagher has not publicly described the exact software path between Command Center and the IN-series locks. ASSA ABLOY commonly uses its Door Service Router, or DSR, for third-party integrations, but public Gallagher materials do not establish whether this implementation uses DSR, a Gallagher-developed service or another interface. Saying that the locks connect directly to the on-premises IP network describes the network topology at the opening; it does not prove a direct application-layer session between each lock and Command Center.
That distinction also helps put the announcement in perspective. Controller-independent intelligent locking is an established architecture, and platforms including Genetec and C•CURE 9000 have supported ASSA ABLOY IP locks before this Gallagher announcement. The September release is significant because it gives Gallagher customers another architectural option—not because the industry has discovered a new type of access-control system.
One product family creates three different network behaviors
Calling both products "IP locks" hides an important design difference. A battery-powered IN120, an externally powered IN120, and an IN220 connected through PoE may all provide intelligent access control at the opening, but they do not behave the same way from a network or operations perspective.
A standard IN120 uses six AA batteries and communicates over Wi-Fi. ASSA ABLOY's IT documentation describes a radio that connects according to a configurable schedule, exchanges data, and powers down between communication sessions. Its generic DSR documentation lists a 24-hour default contact schedule for battery-operated Wi-Fi locks, although Gallagher has not published the synchronization profile used by its own integration.
That means "networked" does not necessarily mean "continuously online." With a battery-powered IN120, configuration changes and some commands can remain pending until the radio makes its next scheduled or event-triggered connection. ASSA ABLOY provides mechanisms that can wake compatible Wi-Fi locks sooner, but it has not publicly documented the exact event and command behavior exposed through Gallagher.
The operating model changes when the IN120 receives external 9 to 24 VDC power. ASSA ABLOY says the lock can then remain associated with the network full time. The opening may look almost identical from the corridor, but the infrastructure behind it is different because the design now needs a permanent power path through a moving door.
IN220 takes the wired approach. It uses Ethernet and IEEE 802.3af Class 1 PoE, with ASSA ABLOY specifying power consumption below 3.84 watts. Because it remains connected as an Ethernet endpoint, it avoids the scheduled-radio behavior of a battery-operated IN120 and supports a much more immediate communications model.
This distinction matters most when analyzing outages. Losing network connectivity does not necessarily prevent either lock from making local access decisions because the local credential database remains at the opening. Losing operating power is a separate event. A battery-powered IN120 naturally separates those two failure conditions, while an IN220 may lose both communications and operating power if its PoE source fails and the surrounding design does not provide the required backup.
Moving controller functions into the lock does not make the lock a controller equivalent
It is tempting to describe this architecture as "controller-less access control," but that phrase hides more than it explains. Enterprise policy still exists above the opening, the integration may depend on server-side software that Gallagher has not publicly detailed, and an intelligent lock does not reproduce every capability of a large enterprise controller.
Gallagher's Controller 7000 Single Door provides a useful comparison because it is already a network-connected, PoE-capable device that can be installed close to a door. In that architecture, however, the controller remains a separate component. It connects to a reader, controls the lock output, accepts multiple inputs, and participates in Gallagher's broader policy model.
With an IN220, more of that physical chain is incorporated directly into the lock assembly. The reader is in the lock, the locking mechanism is internal, credential evaluation occurs locally, and supported request-to-exit and door-position functions can also be part of the opening. A single Ethernet connection can then provide both the IP path and PoE.
The difference is therefore more specific than saying intelligence has moved closer to the door. Gallagher already offers a single-door controller that can sit close to the opening. The IN-series architecture moves reader, lock, network interface, and embedded decision functions into the opening hardware itself.
There are also capacity differences. Gallagher advertises very large credential databases and extensive offline event storage in its C7000 controller family. ASSA ABLOY's July 2026 IN-series catalog lists up to 10,000 users and a 10,000-event audit trail, while older lock generations and particular integrations may support less. The devices overlap in function, but you should not treat them as interchangeable architectural components.
The failure domain shifts from panels toward network infrastructure
Distributing access decisions across intelligent openings changes the shape of failure. A hardware failure in a multi-door controller can affect several openings at once, whereas a failure of an individual intelligent lock is naturally confined to that opening. The shared dependencies, however, do not disappear; they move elsewhere.
A group of IN220 locks may depend on the same PoE switch and UPS. Multiple IN120 locks may rely on the same wireless access point for synchronization and management. Whatever server-side integration Gallagher uses can also become a shared dependency for configuration, visibility, and event handling even while the locks continue making local access decisions independently.
The result is not automatically more resilient or less resilient. A controller-based architecture concentrates several doors behind fewer IP endpoints and common controller infrastructure. An intelligent-opening architecture distributes decision-making more widely while increasing direct dependence on switching, Wi-Fi coverage, endpoint power, and network operations.
PoE itself is not unique to the IN220 architecture. Gallagher's Controller 7000 Single Door can also use PoE and provides battery options. The broader design lesson is that once access-control equipment relies directly on network-delivered power, the switch, UPS, and maintenance model around that network become part of the physical-security failure analysis.
An outage review therefore has to go further than asking whether access decisions continue when the server is unavailable. Designers also need to consider what happens when an access point fails, a PoE switch reboots, a VLAN changes, a certificate expires, or an integration service becomes unavailable. Local access may continue while management visibility, alarms, synchronization, or event reporting are temporarily impaired.
Each opening becomes part of endpoint operations
A traditional access-control deployment may expose a relatively small number of controllers to the IP network while readers, locks, contacts, and request-to-exit devices remain on field wiring behind them. Intelligent IP locks change that ratio. A deployment with one thousand networked openings can potentially create one thousand individually addressed endpoints rather than a much smaller number of controllers serving those same doors.
Routine traffic volume is not necessarily the main concern. ASSA ABLOY's published IT material describes small amounts of normal data per lock. The larger operational shift comes from the lifecycle of the endpoints themselves: IP addressing, switch ports, wireless configuration, authentication, certificates, firmware, device inventory, monitoring, and troubleshooting now extend all the way to the opening.
IN120 makes that relationship with IT particularly visible. ASSA ABLOY documents WPA/WPA2 Enterprise and 802.1X support using EAP-TLS, EAP-TTLS, and PEAP, along with certificate-size and format constraints. The July 2026 catalog still lists WPA/WPA2 rather than WPA3, so you must evaluate compatibility with an organization's wireless-security policy rather than assume it.
The public documentation for the Ethernet side of IN220 is less complete. ASSA ABLOY documents IP addressing, PoE, and optional AES-128 at the lock protocol level, but the public material reviewed for the MASTER did not provide equivalent detail for Ethernet 802.1X, device certificates, secure boot, or firmware signing. That absence is not evidence that those controls do not exist. It is a reason to obtain current security documentation before treating a network-connected lock as ordinary door hardware.
This is where operational ownership becomes important. Physical security still owns the access-control outcome, but the opening may now require switch capacity, wireless coverage, IP addressing, certificate management, firmware coordination, and network troubleshooting. ASSA ABLOY's own product documentation includes a "Facts for IT" guide, which is a useful indication of how much the deployment boundary has expanded beyond traditional access-control wiring.
The announcement still leaves integration questions that matter in design
Gallagher's September announcement provides enough information to understand the architecture, but not enough to engineer every deployment detail from public documentation alone. The exact software path between Command Center and the locks has not been published, and the public material reviewed for the MASTER does not specify the minimum Command Center version or integration build.
Credential support has a similar boundary. ASSA ABLOY offers reader configurations supporting technologies including HID iCLASS, Seos, MIFARE, DESFire, PIV/PIV-I, HID Mobile Access, and wallet-based credentials. Product capability does not automatically establish integration capability, so those options should not be interpreted as a list of credentials Gallagher can necessarily provision or manage through the new integration.
The same caution applies to Gallagher Mobile Connect. The presence of BLE or NFC hardware in a lock is not enough to establish compatibility. Gallagher's public Mobile Connect documentation currently names Gallagher, Aperio, and SALTO devices rather than IN120 or IN220, so support should not be inferred without Gallagher-specific documentation.
Real-time behavior also needs verification at the integration level. IN220 is designed as a continuously connected Ethernet device, but Gallagher has not published a complete command and event matrix for this integration. The synchronization boundary is even more obvious with a battery-operated IN120 because a command directed at a sleeping Wi-Fi lock may need to wait for the radio to wake.
Those are normal engineering questions for a newly announced integration. They don't show the architecture is flawed; they show why a press release isn't a design specification.
The likely future is hybrid access control
Gallagher's ASSA ABLOY integration does not signal the end of the field controller. Large controllers remain appropriate where many openings need extensive I/O, very large credential databases, complex local policy, or a common field architecture. Battery-powered Wi-Fi locks solve a different problem, particularly where running communications cable is expensive or disruptive, while PoE intelligent locks fit locations where wired Ethernet and continuous communication are practical.
That makes hybrid deployments a natural outcome. A facility may use traditional controllers in one area, PoE intelligent openings in another, and battery Wi-Fi locks where retrofit constraints dominate. The important design decision is no longer simply which controller should serve which group of doors; it also includes deciding which openings should become endpoints in their own right.
Once the reader, decision logic, locking hardware, and network interface live together at the opening, network design becomes part of access-control design at a much finer level. Synchronization behavior, switch and AP dependencies, endpoint cybersecurity, power resilience, firmware lifecycle, and responsibility between physical security and IT all become part of the same architectural decision.
The controller functions have not disappeared. They have been redistributed.
That redistribution is what makes Gallagher's new integration worth paying attention to.
Sources and further reading
- Gallagher Security — Gallagher Security and ASSA ABLOY streamline access control with new IP lock integration, September 24, 2026.
- ASSA ABLOY — IN Series IN120 / IN220 Catalog, 45450 07/26, July 2026.
- ASSA ABLOY — Facts for IT, document 4513.C, Revision C, October 2023.
- ASSA ABLOY — DSR Support Tool User Manual, Version 8, August 2020.
- Gallagher Security — Controller 7000 Single Door Datasheet, current product documentation, accessed October 2026.
- Gallagher Security — Aperio Wireless Access Integration, INT184, current integration documentation, accessed October 2026.
- Genetec — Supported ASSA ABLOY IP Lock Features in Synergis Softwire 11.5.3, updated June 16, 2025.
- Software House — C•CURE 9000 ASSA ABLOY IP Lock Integration Guide, v2.90 SP1 C, November 2022.
AI disclosure: The final prose was generated primarily with AI from a human-reviewed, primary-source-verified technical master.
Top comments (0)