When the Door Becomes a Network Endpoint
In a conventional access-control system, the IP network often ends at the controller. The reader, lock, door contact, and request-to-exit devices connect to it through dedicated field wiring. The controller communicates with the management platform, stores enough local data to make decisions when the server is unavailable, and serves as the operational boundary between the enterprise network and the opening.
Gallagher Security’s newly announced support for ASSA ABLOY IN120 Wi-Fi and IN220 PoE intelligent locks moves that boundary. Announced on September 24, 2026, the integration allows supported locks to connect to an organization’s on-premises IP network without a separate field door controller. Command Center still manages privileges, credentials, schedules, overrides, events, alarms, audit information, and device health. AI assisted in drafting this article; we reviewed the technical claims against the primary sources listed below.
The interesting part isn’t that these locks are new-they aren’t. Nor is Gallagher the first enterprise access-control platform to support intelligent IP locks. What makes this integration worth examining is the architectural choice it brings to the Gallagher ecosystem: the reader, locking hardware, local credential database, access-decision logic, and network interface can now all be housed at the opening.
That changes more than the access-control drawing. It changes what “online” means, where failures occur, how power resilience is designed, how many endpoints IT must manage, and which questions need to be answered before a door becomes just another device on the network.
The network boundary moves all the way to the opening.
In a conventional Gallagher-controlled door, the access decision normally sits in a field controller. Readers and I/O devices connect back to that controller over interfaces such as HBUS, OSDP, or Wiegand, while the controller communicates with CommandCenter over IP. Enterprise policy comes from above, but the controller retains local data and logic so it can continue making access decisions when its server connection is interrupted.
The ASSA ABLOY IN-series architecture redistributes some of those functions. The lock itself can incorporate the reader, locking mechanism, request-to-exit functions, event storage, local credential evaluation, and its own network interface. Gallagher states that the new integration does not require a separate field door controller in that path.
That should not be interpreted as proof that each lock communicates directly with Command Center at the application layer. Gallagher has not publicly documented the complete software path between Command Center and the locks. ASSA ABLOY commonly uses its Door Service Router, or DSR, for third-party access-control integrations. Still, the public Gallagher material does not establish whether this implementation uses DSR, a Gallagher-developed service, or another interface.
The distinction matters because “connected directly to the IP network” describes the network topology at the opening. It does not automatically describe every software component between the lock and the management application.
It also keeps the announcement in perspective. Intelligent networked locks already exist in other enterprise access-control ecosystems. What changed in September is Gallagher customers gaining another architecture to choose from — not the invention of controller-independent intelligent locking.
And once that choice exists, the design conversation moves beyond readers and door controllers. Wi-Fi, PoE, endpoint management, synchronization, firmware, and network resilience become part of the access-control architecture itself.
One lock family, three very different operating models
Calling both IN120 and IN220 “IP locks” makes them sound more alike than they are.
A standard IN120 is battery-powered and communicates over Wi-Fi. ASSA ABLOY specifies six AA batteries and describes a radio designed to connect according to a configurable schedule, exchange data, and then power 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 integration.
That operating model changes what "online" means for a device. By default, a battery-powered IN120 is not continuously associated with the wireless network. Some configuration changes or commands can remain pending until the lock reconnects on schedule or after an event that wakes it. ASSA ABLOY documents mechanisms that can wake compatible Wi-Fi locks sooner, but Gallagher has not publicly detailed the exact behaviors available.
The IN120 can also be externally powered at 9 to 24 VDC. In that configuration, ASSA ABLOY says it can remain associated with the network full time. From the hallway, the opening may look almost identical to the battery-powered version. From an infrastructure perspective, it is a different system: continuous communication now requires a permanent power path and the hardware to transfer that power through a moving door.
IN220 takes a third approach. It uses wired Ethernet and IEEE 802.3af Class 1 PoE, with ASSA ABLOY specifying consumption below 3.84 watts. There is no scheduled battery-radio cycle to account for; the lock operates as an Ethernet-connected endpoint with a much more immediate communications model.
Those differences matter most when something fails.
A loss of network connectivity does not necessarily prevent local access decisions because the locks maintain a local database. A loss of electrical power is a separate failure. A battery-powered IN120 naturally separates network availability from its operating power. An IN220 can lose both communications and operating power when its PoE source fails unless the surrounding power and backup architecture has been designed to preserve them.
So the selection between Wi-Fi and PoE is not simply a cabling preference. It changes synchronization behavior, infrastructure dependencies, maintenance requirements, and the failure modes you must evaluate.
The controller did not disappear. Its functions were redistributed.
“Controller-less access control” is tempting shorthand for this architecture, but it obscures more than it explains.
Enterprise policy still exists above the opening. The integration may depend on server-side components that Gallagher has not publicly described. And an intelligent lock does not reproduce every capability of a large enterprise controller simply because it can make a local access decision.
Gallagher’s own Controller 7000 Single Door is a useful comparison. It is already an IP-connected, PoE-capable controller designed to sit near an opening. In that architecture, however, the controller remains a distinct device. A separate reader connects to it, the controller operates the lock output, multiple inputs can terminate there, and the device participates in Gallagher’s broader policy architecture.
With an IN220, more of that physical chain is concentrated inside the lock assembly. The reader and locking mechanism are internal. Local credential evaluation happens at the opening. Depending on the hardware configuration, you can also incorporate request-to-exit and door-position functionality. One Ethernet connection can provide both the network path and PoE.
The important difference, then, is not simply that intelligence moved closer to the door. Gallagher already offered a way to put a controller close to one opening. The IN-series architecture combines the reader, lock, network interface, and embedded controller functions inside the opening hardware itself.
That concentration has practical limits. ASSA ABLOY’s July 2026 IN-series catalog lists capacity for up to 10,000 users and a 10,000-event audit trail, while older lock generations and particular integrations may support less. Gallagher advertises substantially larger credential databases and offline event capacity across its C7000 controller family.
The devices therefore overlap in function but are not equivalent.
For some openings, integrating more functionality into the lock can simplify the physical architecture. For others, the richer I/O, storage, policy capabilities, or field topology of a dedicated controller remain the more appropriate design. The integration adds another option rather than establishing a universal replacement for the panel.
The failure domain starts to look like an IT problem
Distributing access decisions across intelligent openings changes how failures propagate.
A conventional multi-door controller creates an obvious shared failure point: a hardware problem at that controller can affect several connected openings. An individual intelligent-lock failure is naturally more localized because the decision-making device belongs to one opening.
Get Andrii Slobodskyi’s stories in your inbox
Join Medium for free to get updates from this writer.
But shared dependencies don't disappear. They move elsewhere.
A group of IN220 locks can depend on the same PoE switch and UPS. Multiple IN120 locks can depend on the same wireless access point for synchronization and management. Whatever server-side component Gallagher uses for the integration can become a shared dependency for visibility, updates, and management even if the locks continue making local access decisions during a communications outage.
This produces a different failure model, not an automatically better one.
Once door hardware is powered directly from network infrastructure, the switch and its backup design become part of the physical-security failure analysis. Gallagher’s Controller 7000 Single Door shows this consideration isn't unique to the IN220; it can also use PoE, with battery options available. The broader lesson is that PoE-powered access control ties network-power design directly to door availability.
The same principle applies to communications. Saying that a lock can continue making local decisions when the network is unavailable answers only one part of the outage question. Management visibility may be lost. Events and alarms may not reach the central system immediately. Configuration changes may stop synchronizing. A battery Wi-Fi device may already be designed around intermittent connectivity, while a continuously connected PoE lock creates a different operational expectation.
A meaningful resilience review must follow the complete chain. What happens if an access point fails? What if a PoE switch reboots? What if someone changes the VLAN? What if a certificate expires or the integration service becomes unavailable?
“The lock works offline” is useful information. It is not, by itself, an availability design.
Every intelligent opening is also an endpoint to manage
Traditional enterprise access control can expose relatively few controllers to the IP network while leaving large numbers of readers, locks, contacts, and request-to-exit devices behind them. Intelligent IP locks change that ratio.
At scale, 1,000 networked openings can mean 1,000 separately addressed endpoints rather than a much smaller set of controllers serving those same doors. Routine traffic may still be modest; ASSA ABLOY’s own IT documentation describes small data volumes per lock. The bigger operational change is the number of devices that now must be provisioned, inventoried, authenticated, monitored, updated, and troubleshot.
The IN120 makes that convergence with IT particularly visible. ASSA ABLOY documents WPA/WPA2 Enterprise and 802.1X support with EAP-TLS, EAP-TTLS, and PEAP for its Wi-Fi implementation, along with certificate format and size constraints. The July 2026 catalog still lists WPA/WPA2 rather than WPA3, so evaluate compatibility with an organization’s current wireless-security policy rather than assume it.
Public documentation for the Ethernet side of IN220 leaves different questions open. ASSA ABLOY documents IP addressing, PoE, and optional AES-128 at the lock protocol level. Still, the public material reviewed for this article did not provide equivalent detail on Ethernet 802.1X, device certificates, secure boot, or firmware signing.
An absence of public documentation is not evidence that a control does not exist. It is a reason to obtain current technical security documentation before approving a network-connected lock as an enterprise endpoint.
The same caution applies above the network layer. ASSA ABLOY offers reader configurations supporting technologies including HID iCLASS, Seos, MIFARE, DESFire, PIV/PIV-I, HID Mobile Access, and wallet-based credentials. That product capability does not establish which formats Gallagher can provision and manage through this specific integration. Gallagher Mobile Connect should likewise not be assumed compatible simply because a lock contains BLE or NFC hardware; Gallagher’s current public Mobile Connect documentation does not identify IN120 or IN220 as supported devices.
Real-time behavior also needs to be tested against the actual integration rather than inferred from the transport. IN220 is continuously connected over Ethernet, but Gallagher has not published a complete command and event matrix. Battery-operated IN120 has the additional synchronization constraint of a radio that may be asleep when a command is issued. Claims such as instantaneous global lockdown across a battery-powered IN120 deployment therefore need Gallagher-specific documentation before they belong in a design specification.
These are not unusual gaps for a newly announced integration. They are the difference between understanding the direction of a product announcement and engineering a deployment around it.
The likely destination is a hybrid architecture.
Gallagher’s integration with ASSA ABLOY does not make the access-control panel obsolete. It makes the architectural menu larger.
Large controllers still make sense where many openings require extensive I/O, large credential databases, complex local policy, or a common field architecture. Battery-operated Wi-Fi locks can solve a different problem, especially where new communications cabling would be expensive or disruptive. PoE intelligent locks fit another category: openings where Ethernet is practical and continuous connectivity is valuable.
A real facility can use all three.
One area may remain on traditional Gallagher controllers. Another may use IN220 locks where PoE is already available. Retrofit doors that are difficult to cable can use battery-powered IN120 hardware. The result is not a contest to decide which architecture wins; it is a hybrid access-control system whose different opening types have different synchronization, power, network, and lifecycle requirements.
That is why Gallagher’s September announcement is more interesting as an infrastructure story than as a lock announcement.
When the reader, local decision logic, locking hardware, and network interface live together at the opening, the design no longer ends with reader wiring and controller capacity. Switch architecture matters. Wireless design matters. UPS runtime matters. Endpoint authentication, certificate handling, firmware lifecycle, and network troubleshooting matter. Physical security still owns the access-control outcome, but IT becomes an active participant in how the opening operates.
The controller functions have not vanished. They have been redistributed.
And once the opening itself becomes a network endpoint, the network is no longer supporting infrastructure around the access-control system. It is part of the access-control system.
Sources & Further Reading
Gallagher Security — “Gallagher Security and ASSA ABLOY streamline access control with new IP lock integration”
September 24, 2026
https://security.gallagher.com/en/News/Gallagher-Security-and-ASSA-ABLOY-streamline-access-control-with-new-IP-lock-integration
ASSA ABLOY — IN Series IN120 / IN220 Catalog, 45450 07/26
July 2026
https://content.assaabloyusa.com/doc/AADSS1012314
ASSA ABLOY — Facts for IT, document 4513.C
Revision C, October 2023
https://content.assaabloyusa.com/doc/aadss1054756
ASSA ABLOY — DSR Support Tool User Manual, Version 8
August 2020
https://resources.locksandsafes.com/wp-content/uploads/ASSA-ABLOY-DSR-Support-Tool-User-Manual_SWMN21A.pdf
Gallagher Security — Controller 7000 Single Door Datasheet
Current product documentation, accessed October 2026
https://security.gallagher.com/-/media/Bynder/Security/Document/Datasheet/Controller-7000-Single-Door-Datasheet-original.pdf
Gallagher Security — Aperio Wireless Access Integration, INT184
Current integration documentation, accessed October 2026
https://products.security.gallagher.com/security/global/en/products/integrations/aperio-wireless-access-integration/p/INT184
Genetec — Supported ASSA ABLOY IP Lock Features in Synergis Softwire 11.5.3
Updated June 16, 2025
https://techdocs.genetec.com/r/en-US/SynergisTM-Softwire-Integration-Guide-11.5.3/Supported-ASSA-ABLOY-IP-lock-features-in-Synergis-Softwire-11.5.3
Software House — C•CURE 9000 ASSA ABLOY IP Lock Integration Guide, v2.90 SP1 C
November 2022
https://s3.amazonaws.com/compatibilitymatrix/CCURE9000MatrixDocuments/ASSA%20ABLOY/IP%20Enabled%20Locks/Advanced%20Details/ASSAABLOY_IPLock_Integration%20Guide_v2.9.pdf
