Gallagher's support for ASSA ABLOY IP locks puts the access decision inside the door

In a conventional Gallagher opening, the access decision sits in a field controller ^[6]. Readers and I/O connect to it over HBUS, OSDP or Wiegand, and the controller talks to Command Center over IP ^[6]. It also keeps enough local information to go on making decisions when the server link is down ^[6].

The IN-series lock folds that chain into one assembly and connects to the on-premises IP network with no separate field door controller ^[2]. It holds the reader, the locking mechanism, the decision logic, event storage and the network interface, plus request-to-exit and door-position functions in some hardware configurations ^[7]. Command Center keeps the policy layer above it ^[3]. A dev.to analysis of the integration argues that once the credential database and decision logic sit at the opening, duties that used to live behind the access-control panel move onto the network ^[13].

Power decides how that network behaves. A standard IN120 runs on six AA batteries and talks over Wi-Fi ^[9]. ASSA ABLOY's IT documentation describes a radio that connects on a configurable schedule, exchanges data and powers down between sessions ^[9]. Its generic Door Service Router (DSR) documentation sets a 24-hour default contact schedule for battery Wi-Fi locks, though Gallagher has not published the profile its own integration uses ^[10].

So a networked lock is not necessarily an online one ^[11]. On a battery IN120, configuration changes and some commands can sit pending until the next scheduled or event-triggered connection ^[11]. If the 24-hour default applied, a change queued just after a check-in could wait close to a day ^[16]. ASSA ABLOY has mechanisms that can wake compatible Wi-Fi locks sooner ^[11]. I'd put battery IN120s only on doors where a scheduled check-in is an acceptable delay for a policy change, and run PoE or external power to the rest.

The integration path is the other open item. Gallagher has not publicly described the software path between Command Center and the locks ^[8]. ASSA ABLOY commonly routes third-party integrations through DSR, but Gallagher's public materials do not establish whether this one uses DSR, a Gallagher-built service or another interface ^[8]. The analysis is careful on this point. A lock on the on-premises IP network describes the topology at the door, and it does not prove each lock holds its own application session with Command Center ^[14]. The source does not cover segmentation guidance. I would not write firewall rules for these doors until that path is documented, because the permitted flows depend on which host the locks talk to.

None of this is a new architecture. Genetec and C-CURE 9000 supported ASSA ABLOY IP locks before Gallagher's September 24, 2026 announcement ^{[4] [1]}. Gallagher is still developing its Controller 7000 family ^[5]. Its customers now have another topology to choose from, and the choice moves where power, communications, failure handling, endpoint security and operational ownership have to be engineered ^[15].