DEV Community: Andrii Slobodskyi

Why PTZ Cameras Shouldn’t Own Your Baseline Coverage

Andrii Slobodskyi — Fri, 30 Oct 2026 17:13:00 +0000

A PTZ camera can provide an excellent close view of an incident. However, the moment an operator turns it toward that incident, it stops looking at whatever was previously in frame.

That basic limitation becomes important at the scale of Mercedes-Benz Stadium in Atlanta. On October 20, 2026, Axis Communications published details of a surveillance modernization already operating at the venue, where more than 70,000 visitors and employees may be present on peak event days. The project uses overlapping fixed cameras to cover the seating bowl, with separate PTZ cameras available for investigation.

Axis and stadium personnel also reported two notable outcomes: image detail in the seating bowl increased from roughly 20 to 80 pixels on target, and fan exit time during one soccer match reportedly fell from 16 minutes to eight after personnel used camera views to identify congestion and redirect spectators.

Both numbers need context. The more transferable engineering lesson is the architecture behind them: continuous observation and active investigation are different surveillance functions, and one camera type does not have to perform both.

Separate the coverage layer from the investigation layer

A PTZ offers something a fixed camera cannot: an operator can move the view, follow activity, and use optical zoom to examine a distant event in more detail. That flexibility is valuable in a stadium, but it creates an unavoidable trade-off. Once the camera moves, it no longer observes the previous scene from that viewpoint.

Mercedes-Benz Stadium addresses that problem by giving fixed and PTZ cameras different jobs. Axis says overlapping fixed cameras maintain seating-bowl coverage, while 4K PTZ cameras installed in the bowl and on the scoreboard provide a separate investigation capability. The published material identifies the AXIS Q18 Bullet Camera Series and AXIS Q63 PTZ Camera Series operating with Genetec video management software, although it does not provide a complete camera schedule, exact installed models, or total system camera count.

That distinction matters because an operator investigating a disturbance, medical event, or other developing situation does not have to sacrifice the baseline view of the surrounding seating section. The PTZ can move toward the incident while fixed cameras continue providing context.

From a design perspective, this is more robust than treating a powerful PTZ as the camera responsible for both overview and investigation. Optical zoom can dramatically improve detail, but zoom does not solve continuity. A movable camera cannot preserve its previous field of view while simultaneously looking somewhere else.

Stable coverage also has operational value beyond security incidents. Axis describes staff using the improved seating-bowl views to help locate spectators requiring medical assistance and confirm their seating sections. In those cases, persistent spatial context can be more useful than a camera that is continuously repositioned.

Optical overlap is not the same as system redundancy

Axis says the fixed-camera views were deliberately overlapped so that losing one camera would not leave a seating section unobserved. That is a meaningful resilience objective, but it protects against only one class of failure.

Suppose two cameras provide sufficient overlap over the same seating section. If both cameras depend on the same access switch, PoE source, UPS, or upstream network path, a shared infrastructure failure can remove both views at once. The optical layout may be redundant, but the supporting system may not be.

Public material does not disclose the stadium's switch topology, UPS architecture, camera distribution, or failure-testing methodology, so these sources cannot establish the level of infrastructure redundancy in the actual deployment. That uncertainty should remain separate from Axis's documented claim about overlapping fields of view.

For an integrator, these are two different acceptance questions. The first is whether the remaining camera provides enough useful coverage and image detail after one camera fails. The second is whether the supposedly redundant views survive failures elsewhere in the infrastructure.

A useful conceptual model is:

Coverage resilience
    |
    +--> Optical resilience
    |       +--> overlapping fields of view
    |       +--> usable remaining image detail
    |
    +--> Infrastructure resilience
            +--> switching
            +--> PoE / power
            +--> UPS
            +--> upstream network paths

The first layer is visible on a camera layout drawing. The second requires understanding how those cameras are actually powered and connected.

This is why "we have overlapping cameras" should not automatically become "we have redundant surveillance." You have to trace the failure domain beyond the lens.

Pixel density is more useful than megapixels, but only when the metric is defined

One of the most interesting figures in the case study is the reported increase from roughly 20 to 80 pixels on target in the seating bowl. That is more useful to a surveillance designer than simply saying the replacement cameras have more megapixels because it describes the detail available at the subject.

However, the public material does not define the measurement precisely. Neither Axis source specifies whether the figure means pixels per unit of distance, pixels across a particular target dimension, or another metric. The measurement point, lighting conditions, and test methodology are also not published.

That limitation matters when interpreting a fourfold increase. If a value represents a linear pixel-density measurement, multiplying it by four is not equivalent to saying the target contains four times as many total sampled pixels. Under comparable geometry, quadrupling linear resolution in both dimensions would correspond to roughly sixteen times as many pixels across the same two-dimensional target area. That is a mathematical illustration, not a verified calculation for this stadium installation.

Axis describes the modernization as significantly improving detail and refers to quadrupled image quality in its customer case study. Image quality itself is broader than one resolution metric. Optics, stabilization, lighting, compression, exposure, subject motion, and camera placement can all affect what an operator ultimately sees.

Axis also says the stadium's new cameras exceed an NFL requirement of 50 pixels on target. The source material reviewed for the MASTER did not provide an independently accessible NFL technical specification confirming that requirement, so the figure should remain attributed to Axis and stadium personnel rather than presented as independently established league documentation.

The engineering lesson is not that the 80-pixel figure is unimportant. It is that performance targets need definitions. During design and acceptance, a number is useful only when everyone understands what it measures, where it is measured, under what conditions, and what operational task that level of detail is intended to support.

Better camera coverage still depends on the surrounding infrastructure and operations

The stadium modernization extends beyond the seating bowl. Axis describes long-range rooftop PTZ cameras to monitor surrounding traffic and approaching crowds, as well as an integration with the stadium's drone-detection system.

The two Axis publications differ slightly in how they describe that integration. The press release associates it with rooftop PTZ cameras, while the customer case study refers more generally to Axis PTZ cameras. Neither publication names the drone-detection vendor, describes the interface, or establishes that a camera automatically slews toward a detected drone.

The video system also sits inside a much broader operational environment. GC&E Systems Group served as the project integrator, and Axis identifies Genetec as the VMS, but the public material does not describe the deployment's storage architecture, software topology, or detailed network design.

An independent Security Management article from ASIS International describes a stadium operations center that runs continuously and brings multiple organizations together during events. Representatives from stadium departments, Atlanta Police, Fire Rescue, and Emergency Medical Services can coordinate through that operating environment while surveillance, weather, and other information are monitored.

That context helps explain why the reported improvement in fan exit time cannot reasonably be attributed to cameras alone.

According to stadium personnel, operators used the video system to identify congestion and then communicated with officers, who redirected spectators toward less crowded exits. The stadium reports that exit time during one soccer match fell from 16 minutes to eight.

The exact match, definition of "exit time," and comparison baseline have not been published. The result should therefore be treated as a customer-reported operational outcome rather than a general performance benchmark for the surveillance system.

More importantly, the workflow involved both technology and people:

Camera observation
        ↓
Operator recognizes congestion
        ↓
Information reaches personnel
        ↓
Officers redirect spectators
        ↓
Crowd flow changes

Improved image detail can support the first stages of that process, but it doesn't complete the operational response.

Stable views can also create a better foundation for future analytics

Mercedes-Benz Stadium has discussed computer vision as a possible future step for studying queues and helping personnel direct spectators. Those functions are described as future development rather than capabilities already deployed in the project.

The existing separation between fixed coverage and PTZ investigation is relevant here for another reason. A fixed camera provides a stable scene geometry, while a PTZ changes its field of view whenever an operator moves, zooms, or repositions it. For analytics that depend on consistent spatial relationships, a stable view can provide a more predictable observation surface.

That is an engineering consideration, not a claim about what the stadium's future analytics will do. A camera layout designed for human monitoring does not automatically become a validated measurement system for crowd flow.

Any future analytics would still require appropriate camera positioning, calibration, environmental testing, and performance validation. Lighting variation, occlusion, crowd density, camera perspective, and other site conditions can affect the result even when the underlying video is excellent.

The broader lesson is that camera architecture can either help or complicate whatever comes next. Designing a stable baseline layer today can preserve options for future analytics without requiring PTZ cameras to stop performing their investigation role.

Commissioning should verify coverage and failure behavior separately

The Mercedes-Benz Stadium project points to a useful commissioning principle for other large surveillance systems.

First, test coverage performance. Confirm that the fixed-camera layout provides the required views and image detail across the operational area. Where overlap is intended to survive the loss of one camera, disable or isolate a camera during acceptance and verify that the remaining view still meets the agreed requirement.

Then test infrastructure failure behavior separately. If overlapping cameras share a switch, power source, or network path, understand what happens when that shared component fails. A coverage drawing alone cannot answer that question.

PTZ behavior also deserves its own acceptance criteria. Confirm that operators can use PTZ cameras for investigation without unexpectedly losing baseline coverage elsewhere. Presets, usable zoom ranges, low-light performance, stabilization, latency, and operator workflow may all matter depending on the project's requirements.

Finally, connect the camera system to the actual response procedure. An excellent image has limited operational value if personnel cannot locate the event, retrieve relevant views, communicate the information, or act on it in time.

These are not stadium-specific requirements. They apply anywhere surveillance has to do two jobs at once: maintain awareness of a large area and let an operator investigate something in detail.

The architecture matters more than the individual camera

The most transferable part of the Mercedes-Benz Stadium modernization is not a particular Axis model or a headline resolution figure. It is the decision to keep continuous observation and active investigation as separate surveillance layers.

Fixed cameras maintain the seating-bowl view. PTZ cameras can look elsewhere when the situation requires it. Optical overlap provides one form of resilience, while switches, power, UPS design, and network paths determine another. Image-detail targets provide useful design criteria only when their measurement and operational purpose are understood.

The reported crowd-flow result reinforces the same systems lesson. Better images supported better decisions, but personnel still interpreted those images and changed conditions on the ground.

A PTZ is most valuable when it can investigate freely.

That freedom is much easier to use when the rest of the surveillance architecture does not have to look away with it.

Sources and further reading

Axis Communications — Mercedes-Benz Stadium Enhances Fan Safety and Experience with Advanced Video Technology, October 20, 2026.
Axis Communications — Stadium Security Makes for a Better Fan Experience, customer case study.
ASIS International / Security Management — Inside Security at the Mercedes-Benz Stadium, September 16, 2026.

AI disclosure: The final prose was generated primarily with AI from a human-reviewed, primary-source-verified technical master.

A Security Robot Can Be Online and Still Miss the Patrol

Andrii Slobodskyi — Sun, 25 Oct 2026 21:22:00 +0000

A security robot can be online, healthy, and reporting telemetry while still failing to perform its assigned security task.

Imagine an autonomous patrol unit working an overnight route around a data center. Its cameras are operational, the battery is healthy, and the fleet platform continues receiving status updates. During the shift, construction near a loading dock blocks part of the approved route. The robot remains technically available, but it never completes that section of the patrol.

That scenario is hypothetical, but the distinction is real. Device availability, patrol completion, and verified security coverage are three different things.

That difference becomes more important as autonomous equipment moves from demonstrations into contracted security services. A customer is not ultimately paying for a robot to remain connected to the network. The customer is paying for a security function to be performed.

Uptime does not prove that a security task happened

Physical-security systems already rely heavily on equipment-health monitoring. A VMS can report whether a camera is connected and recording. An access-control platform can identify an offline controller. Intrusion systems supervise devices and communication paths so operators know when a fault could compromise detection.

Those states are essential, but they describe equipment condition rather than the full operational outcome. A camera can be online while its view is obstructed. An access-control controller can be healthy even if a required physical inspection never occurs. Autonomous patrols introduce the same distinction while adding another variable: the device must physically move through an environment and complete an assigned activity.

A useful way to model the problem is to separate three states.

First, the robot is technically available. Its communications, navigation, sensors, and supporting functions operate within expected limits.

Second, the robot has completed the assigned task. It followed the approved route or inspection plan and met the documented completion criteria.

Third, the security operation has evidence of that completion. The responsible team can verify what happened, identify exceptions, and respond when the required activity was not completed.

Those states overlap, but none proves the next one. A connected robot may encounter a blocked route. It may finish its navigation sequence while the video required for verification is unavailable. Its fleet system may record an event correctly while that event never reaches the customer's security operations workflow.

This is the engineering problem behind what I call Verifiable Security Coverage Continuity: a defined method for connecting assigned security tasks, performance evidence, detected interruptions, and the procedures used to restore coverage.

That term is not an existing industry standard, and it is not presented as a newly discovered robot capability. Patrol-management systems and managed-security platforms already provide pieces of task tracking, monitoring, and incident documentation. The opportunity is to make those pieces more consistent across autonomous equipment, conventional physical-security systems, and the service agreements that define what the customer is actually supposed to receive.

The objective is deliberately narrower than proving that a robot "secured" an area. Passing a waypoint does not demonstrate that every relevant condition was observed, and a completed patrol does not guarantee threat detection or prevent an incident. The useful question is whether an agreed activity occurred, whether exceptions were visible, and whether the security operation took a traceable action when it did not.

The industry is already combining robots, monitoring, and guarding

Security robotics isn't starting from scratch. Universal Protection Service, a predecessor of Allied Universal, introduced an autonomous robot service with Knightscope in 2016. The offering included K5 outdoor and K3 indoor patrol robots, with security officers trained to incorporate the technology into existing operations.

Allied Universal announced another Knightscope partnership through its Technology Services business in 2022. By then, the service model already included robotic equipment, software, charging infrastructure, technical support, and human response. Allied Universal also operates a Monitoring and Response Center, or MaRC, supporting multiple security technologies, including autonomous devices.

Other parts of the industry have been moving toward the same convergence from different directions. Securitas expanded its electronic-security capabilities by acquiring Stanley Security. Knightscope acquired Event Risk in 2026, adding licensed guarding services to its developing managed-security model. Knightscope has also publicly promoted combining autonomous equipment, monitoring, and human response under one managed service.

SoftBank brings another relevant history. SoftBank Robotics America acquired Green Clean Commercial in March 2026 as part of its Smart Building X initiative, combining people, robots, operational software, and facilities-management data. In October, SoftBank Robotics Singapore and SJ Integrated Solutions announced work on AI-supported facilities management, including service-robot pilots and potential integration with elevators, doors, and access control. That announcement describes development work rather than a completed security-robotics deployment.

The financial context brought additional attention to the subject. On October 16, 2026, Bloomberg and Reuters reported that SoftBank Group was considering acquiring Allied Universal. The reports described a possible equity valuation of up to $18 billion, while Bloomberg's estimate approached $30 billion including debt. As of October 18, the discussions were preliminary, and no acquisition agreement had been announced.

Whether that transaction ever happens is less important to the engineering question. The industry already knows how to package robots, security officers, monitoring, and technology services together. The unresolved issue is how consistently that service performs across different facilities, networks, weather conditions, layouts, operating procedures, and building systems.

A robot being online tells us very little on its own.

A coverage record should describe the task, not just the machine

A practical implementation of verifiable coverage would begin with the security assignment rather than with device telemetry.

For each scheduled activity, the system would need to identify what was supposed to happen, when it was supposed to happen, who or what was responsible, which route or inspection points applied, and what evidence was required to establish completion. When an interruption occurred, the record would need to show when it was detected, how it was escalated, who assumed responsibility, and whether the required coverage was restored, reassigned, or formally changed.

A data center campus illustrates why this matters. The site may include multiple buildings, parking areas, loading zones, generator yards, controlled vehicle gates, and a perimeter fence. Fixed IP cameras feed a VMS, the access-control system manages authorized movement, intrusion and perimeter systems generate additional alarms, and security personnel respond through established procedures.

An autonomous ground robot could supplement selected exterior patrols where the route and environmental conditions fall within its validated operating limits. Depending on the equipment and deployment, it might provide mobile video observations, perform scheduled inspections, or report unusual conditions encountered along its route.

The important design change is to represent each patrol as an operational assignment rather than a simple machine schedule.

If a robot encounters an unexpected obstacle near a generator yard, the significant event is not merely "navigation error." The security event is incomplete patrol coverage. That exception should reach the people responsible for the site's security operation so they can decide what happens next.

Depending on the approved procedure and available capabilities, an operator might investigate the obstruction, assign another device, authorize an adjusted route, or send an officer to cover the affected area. The right response depends on the site, but the gap should not remain hidden behind a green device-health indicator.

Integration with existing physical-security systems makes the problem more demanding. If the robot reports suspicious activity, an operator may need to correlate its recording with fixed-camera video, access events, and intrusion alarms. Clock synchronization, event classification, retention periods, and location quality matter because operators may need to reconstruct an incident across several independent platforms.

None of that compatibility should be assumed. Integrate a particular robot, VMS, or ACS only through supported interfaces, manufacturer documentation, and site testing.

The communications layer deserves the same scrutiny. A patrol robot is a moving network endpoint, often carrying telemetry and video through areas affected by walls, parked vehicles, steel structures, changing RF conditions, and outdoor transitions. Wireless coverage that works perfectly for stationary devices may not provide reliable connectivity across the full patrol route.

That makes route-based wireless surveys, roaming behavior, segmentation, controlled remote access, and response to connectivity loss part of the security design. Cellular connectivity may offer another communications option in some environments, but it comes with its own costs, coverage, and security requirements.

Physical conditions can interrupt a patrol even when every digital system is healthy. Snow, ice, drainage, uneven surfaces, temporary construction, vehicle traffic, and newly restricted areas can make a previously approved route inaccessible. Critical-infrastructure designs therefore need to account for the possibility that scheduled coverage will sometimes have to be restored through a different method.

Robot-ready infrastructure should be designed before deployment

Many physical-security projects are still designed primarily around fixed devices: cameras, readers, controllers, intrusion sensors, network switches, power supplies, and monitoring stations. Mobile autonomous systems introduce a different set of dependencies, and teams often address them only after selecting a robot and fleet platform.

A more disciplined approach would treat Robot-Ready Security Infrastructure as a design consideration where future autonomous operations are reasonably anticipated.

This is also a proposed engineering direction, not an established standard. The idea is simply to avoid rebuilding the same supporting infrastructure every time a new mobile platform is introduced.

Wireless design would consider approved robot routes in addition to fixed endpoints. Network-security architecture would define how telemetry, video, control functions, and vendor maintenance access are segmented and authenticated to meet the product's requirements.

Charging infrastructure would become part of the site plan rather than an afterthought. Locations need suitable electrical service, physical protection, and placement that does not interfere with emergency egress or operational traffic.

Building interfaces require even more discipline. Autonomous devices may eventually need controlled interaction with doors, elevators, or vehicle gates, but existing security and safety requirements still govern those systems. A robot should receive only the permissions required for an approved operation, and those permissions should be manageable and revocable.

Some enabling technologies already exist. Otis Integrated Dispatch provides cloud-based or on-premises APIs that can connect compatible service robots with supported Otis elevator systems. Open-RMF, an open-source robotics middleware framework, provides interfaces for coordinating robot fleets and selected building functions, including doors and lifts.

Those tools can reduce repeated custom integration work, but neither creates universal interoperability. You still have to evaluate the specific robot, elevator, door hardware, access-control system, network, and safety requirements for each deployment.

Lifecycle management matters as much as initial installation. Navigation maps, device identities, credentials, firmware versions, network configuration, and supported building integrations all make up the operational configuration. If the building layout changes or the wireless network is redesigned, you may need to retest the robot's approved security task.

Robot-ready infrastructure does not mean every building should have autonomous patrols. It means sites with a credible use case can systematically prepare the supporting environment rather than discovering critical dependencies after deployment.

Commissioning should test the failed patrol, not just the successful demo

A demonstration proves that a robot can perform a route under the conditions of that demonstration. It does not prove that the security operation can rely on the service.

Commissioning should start by confirming the physical environment and the approved operating boundaries. Charging stations, electrical service, surfaces, wireless infrastructure, patrol maps, restricted zones, and supported building interfaces should match the approved design. Stakeholders should know which routes have been accepted and which areas remain outside the robot's scope.

The next step is end-to-end workflow testing. Assign a scheduled patrol, let the robot run it, and confirm that the required completion evidence reaches the people or systems responsible for monitoring. Simulate a relevant security event and verify that operators receive the expected information, can retrieve the necessary recordings, and can follow the prescribed response procedure.

The more revealing tests are usually the failures.

Block part of an approved route and verify that the system reports an incomplete patrol rather than treating the remaining navigation sequence as success. Interrupt the network in a controlled manner and determine whether the robot enters its documented safe state and whether the security team recognizes that coverage has been affected.

Where relevant, commissioning can also include charging failures, unavailable fleet services, software changes, and modified layouts. Each test needs an expected result, acceptance criteria, and a record of what actually happened.

Connections to doors, elevators, and vehicle gates require coordination with the responsible installation and maintenance contractors. Any interaction involving emergency egress, fire safety, or life-safety systems must remain consistent with applicable codes, approvals, and operating requirements.

Detection performance needs separate treatment. A robot can reliably complete its route and deliver every event while the underlying analytics still generate excessive false alarms or fail to detect relevant conditions. Device safety, event-delivery reliability, patrol completion, and detection quality are separate forms of assurance.

Final acceptance documentation should make both successful and unsuccessful operations reconstructable. That means preserving the assignment, task result, relevant evidence, detected exceptions, operator actions, and recovery procedure.

For the service provider, those records provide a defensible way to demonstrate what was delivered. For the customer, they provide a better basis for deciding whether the system is ready for operational use.

Commissioning also cannot be treated as permanent proof. Changes to firmware, Wi-Fi infrastructure, navigation maps, building layouts, or connected security systems may require targeted retesting because the conditions under which the original acceptance was performed no longer exist.

The contract needs to account for the missing patrol

Technical verification becomes even more important when autonomous patrols are sold as an ongoing service.

Allied Universal's published Robot Machine-as-a-Service terms from November 2019 are an instructive historical example. The document addressed autonomous security equipment, communications requirements, customer responsibilities, maintenance, and service availability. It assigned certain network obligations to the customer, did not unconditionally guarantee robotic-service availability, and described prorated credits for specified maintenance-related service suspensions.

Those terms do not represent every current Allied Universal agreement, and individual customer contracts may contain different or additional provisions. The document shows that robotics services have long had divided technical ownership and commercial remedies.

That division becomes more consequential when the machine is expected to perform a recurring security function.

A robot can miss a patrol because of its own hardware, the customer's wireless network, a charging failure, an outdated navigation map, construction, or an unavailable building interface. The technical owner may shift from one failure to another, but the operational result may be the same: an assigned security activity did not occur.

A mature service model therefore needs more than a table describing who repairs which component. It needs a defined response to the loss of that security function.

The customer and provider can establish approved patrol schedules, completion evidence, escalation rules, authorized changes to coverage, and the conditions that require another device or a human officer to take over. Responsibilities for firmware, navigation maps, recordings, device identities, vendor access, and infrastructure maintenance can remain explicitly assigned without pretending that one contractor controls every cause of failure.

This does not make autonomous security infallible, and it does not guarantee that every threat will be detected. It creates a clearer operational agreement about what happens when the intended coverage is interrupted.

A credit for downtime and restored security coverage are not the same thing.

The economics should follow the security function

Security robotics is often evaluated by comparing a subscription price with an hourly guarding rate. That comparison is attractive because it is simple, but it can hide the actual operating model.

A robot performing an eight-hour patrol window does not necessarily replace eight hours of human work. Security officers may still be required for physical response, visitors, emergencies, access disputes, investigations, and tasks that require judgment or interaction with people.

A deployment may instead increase patrol frequency without reducing headcount. It may allow officers to spend less time on repetitive rounds. In another environment, demonstrated performance and operating requirements might support reducing selected contracted hours.

Those are different outcomes and should be measured separately.

The customer's cost also extends beyond the machine. Depending on the architecture, it can include subscription fees, integration, wireless upgrades, charging infrastructure, monitoring, maintenance, insurance, and the human response required when the robot cannot complete its task.

The provider also has support costs: fleet operations, service technicians, monitoring workload, replacement equipment, downtime coverage, and the margin needed to sustain the service.

Knightscope's fiscal-year 2025 Form 10-K provides a useful caution about reducing technology services to hardware pricing. The company reported approximately $7.97 million in service revenue against $12.32 million in service costs. Those figures combine autonomous robotics and emergency communication device services, so they cannot be used to calculate the robot business's profitability alone.

They do illustrate why service economics depend on more than the advertised equipment price.

A stronger business case would measure the actual coverage added, work transferred from officers, any guard hours genuinely removed, the customer's total cost, the provider's sustainable operating cost, and the expense of backup response when autonomous service is unavailable.

For a data center, industrial site, or other critical facility, a higher total cost may still be reasonable if the program delivers measurably better and more consistent security coverage. Counting robots deployed does not establish that result.

The next useful metric is whether the security function can be proven

Autonomous security systems will continue improving. Navigation will become more capable, sensors will improve, fleet coordination may become more sophisticated, and building integrations will likely become easier to deploy.

Some sites will remain difficult. Weather, crowds, changing layouts, complex access boundaries, and tasks requiring direct human judgment cannot be solved simply by adding more autonomous machines.

For that reason, progress may depend as much on engineering practice as on robotics hardware. Manufacturers can expose better-supported interfaces. Security platforms can improve how they consume robot status and events. Integrators can build repeatable commissioning procedures. Service providers can make task completion and failure recovery explicit parts of the operating model.

The reported SoftBank and Allied Universal discussions may eventually become relevant to that evolution if they proceed, but the underlying requirement exists regardless of any transaction. Robotics manufacturers, security providers, integrators, and customers all face the same question once a machine becomes responsible for an operational security task.

The industry already knows how to monitor whether a device is online.

The harder requirement is to show whether the assigned security activity took place, what evidence proves it, how an interruption was detected, and how coverage was restored when the machine couldn't complete the job.

That is a much more useful measurement than uptime alone.

The security robot was online. The patrol wasn't. A dependable autonomous security service has to know the difference.

Sources and further reading

Bloomberg — SoftBank Is Said to Weigh Buying Top US Security Firm Allied, October 16, 2026.
Reuters — SoftBank weighs $18 billion acquisition of Allied Universal, October 16, 2026.
Allied Universal — Robot Machine-as-a-Service Terms, November 2019.
Universal Protection Service — Autonomous Robot Service, July 2016.
Allied Universal — Knightscope Partnership, February 2022.
Allied Universal — Monitoring and Response Center.
Knightscope — One Throat to Choke, May 2026.
Knightscope — Fiscal Year 2025 Form 10-K.
SoftBank Robotics — Smart Building X, March 2026.
SoftBank Robotics — SJ Integrated Solutions Collaboration, October 2026.
Otis — Integrated Dispatch for Service Robots.
Open-RMF — Fleet and Building Integration Documentation.

AI disclosure: The final prose was generated primarily with AI from a human-reviewed, primary-source-verified technical master.

When a Camera Alert Launches a Drone: The Architecture Behind Verkada + Skydio

Andrii Slobodskyi — Sun, 18 Oct 2026 15:58:29 +0000

A camera alert can now initiate an aerial response workflow. That sounds like a straightforward extension of video surveillance, until the alert becomes a real flight.

On September 16, 2026, Verkada announced its first drone integration with Skydio. A configured alert in Verkada Command can initiate a Skydio deployment workflow, aerial video can return to Command alongside fixed-camera feeds, and the drone's position can appear on Verkada Maps. The integration is currently described as a private beta, and the vendors have not published a named customer deployment or measured results for the combined system.

For security and infrastructure engineers, the interesting work begins after detection. A fixed camera can identify something that deserves attention, but an aerial response still has to decide where to go, whether the aircraft can launch, whether all connected systems remain available, and how the resulting footage becomes usable evidence.

From a fixed-camera alert to a mobile response

The integration connects two systems with different responsibilities. Verkada Command remains the environment for fixed-camera monitoring and alert rules, while Skydio manages the drone-side workflow.

According to Skydio's integration documentation, when a configured Verkada alert is triggered, Verkada sends the triggering camera's GPS coordinates and event video to the Skydio platform. Skydio then handles the aircraft-side response, based on the customer's configuration and operating authority.

The aerial feed can return to Verkada Command, where operators can view it alongside the existing security-camera environment. Verkada Maps can show the aircraft's live GPS position, and operators can access nearby fixed-camera feeds for additional context. Skydio also says it can include aerial footage in Verkada Command incident reports.

That integration creates a more unified operator experience, but the division of responsibilities remains important. Verkada Command is not the aircraft's flight-control system. Skydio still handles navigation, mission execution, and the flight operation itself.

This isn't the first time a video-management platform has connected to drone operations. Skydio already documents integrations with Genetec Security Center and Milestone XProtect, including event-triggered workflows. The Verkada announcement adds that model inside Verkada's cloud-managed security environment.

A camera location is not necessarily the incident location

The location handoff is one of the most important boundaries in the architecture.

Both vendors describe the data sent to Skydio as the triggering camera's GPS location. Their public documentation does not describe a separate coordinate representing the person, vehicle, or other activity that caused the alert.

Those two positions can differ widely. A fixed camera mounted on a building may watch a fence line tens or hundreds of feet away. A PTZ camera can observe activity across an even larger area, so the camera's physical position tells the drone where the sensor is located without necessarily identifying the exact point in its field of view that requires investigation.

Verkada's own configuration documentation introduces another practical question. Command lets you configure a camera's geographic location by entering an address, and it uses that value for map placement and time-zone settings. The public integration documentation does not establish which specific location field is passed to Skydio or whether it always represents the camera's exact mounting coordinates.

That distinction may not matter much when the goal is simply to display cameras on a site map. It matters considerably more when geographic data becomes an input to a mobile response.

Commissioning therefore must treat camera location as operational data rather than metadata. An engineer needs to understand how accurately each camera is represented, how its coverage area relates to that point, and how an operator identifies the actual event location after the initial handoff.

Skydio provides broader flight capabilities for redirecting aircraft and tracking moving subjects, but the published material does not establish that the Verkada integration automatically identifies and acquires the particular object that triggered the original fixed-camera event. Autonomous navigation should not be confused with automatic understanding of where the original incident is occurring.

An alert can request a mission, but it cannot grant flight authority

The second boundary sits entirely outside the video system.

Skydio Security Command supports different launch models. In some configurations, a remote operator can authorize a flight, while in others an aircraft can launch from a trigger when the organization's operating authority permits that mode. Skydio says most programs begin with operator-authorized launches.

The software can automate flight preparation and navigation, but aviation responsibility does not disappear. A qualified remote pilot remains responsible where applicable, and the public documentation does not specify exactly which launch modes are exposed through the current Verkada private-beta integration.

For large industrial or commercial properties, this distinction is fundamental. A security operations center may process many camera alerts every day, while drone operations face a separate set of constraints: airspace, weather, aircraft readiness, flight restrictions, pilot availability, and the organization's regulatory authority.

In the United States, commercial drone operations generally fall under FAA Part 107, with beyond-visual-line-of-sight operations and certain other arrangements requiring the appropriate waiver or other applicable authorization. Canada has its own framework, including Level 1 Complex operations for eligible lower-risk BVLOS scenarios subject to specific requirements for the operation, pilot, aircraft, and airspace.

Owning the property does not by itself remove those aviation requirements. Autonomous flight capability is therefore not equivalent to permission to launch whenever a camera generates an alert.

That has a direct consequence for incident-response design. The security workflow still needs a defined fallback when the requested flight cannot legally or safely occur. Remote video verification, conventional guard response, or another established procedure remains necessary, not obsolete.

The integration creates a longer failure path

Traditional CCTV designs already have failure domains, but linking an alert to an autonomous aircraft extends the chain considerably.

A camera may continue recording even when a remote monitoring connection is unavailable. A drone response requires more systems to succeed in sequence: the alert must be generated, the integration must receive it, the Skydio environment must accept the request, the aircraft and dock must be ready, the flight must be authorized, and the returning aerial video must remain available to the operator.

Skydio documents a general VMS streaming architecture in which drone video uses RTMP and is exposed to VMS applications through an RTSP translation layer. Its documentation lists Verkada among supported VMS environments, but it has not published the exact media path or relay location used by this integration.

That documentation boundary matters when designing monitoring and escalation. If Verkada generates an alert but Skydio never receives the request, the operator needs to know how that failure is exposed. If the aircraft launches while its video doesn't appear in Command, the operating procedure needs to define whether the investigation can continue through Skydio and how to record that condition.

The current beta documentation does not publicly answer those questions. They are therefore commissioning tests, not assumptions.

Aircraft availability adds another layer. Skydio documents weather checks, aircraft-readiness checks, connectivity requirements, and charging considerations. A perfectly functioning integration cannot make an aircraft available when the dock, battery, weather, communications, or another active mission prevents deployment.

The result is a useful additional response capability, but one that needs the same treatment as any other operational security subsystem: documented dependencies, defined degraded modes, alarms that operators understand, and tested fallback procedures.

A single incident can create evidence in two systems

Aerial video also introduces an evidence-management boundary.

Skydio documents timestamps, GPS-tagged flight information, and SHA-256 hashing for captured evidence. Verkada provides its own incident-management and video-archive capabilities, as well as Verkada Verify for checking the integrity of supported video archives downloaded from Command. The integration documentation also states that drone footage can be added to Verkada incident reports.

Those functions do not by themselves establish an end-to-end evidence-integrity process between the platforms. The public material does not specify whether an item transferred into a Verkada incident represents the complete original Skydio recording or selected footage, whether Skydio's original capture hash accompanies that transfer, or how records in the two systems are reconciled.

That becomes important when an event moves from live response to a formal investigation. A security team could have the original flight record in Skydio, an aerial clip associated with a Command incident, and fixed-camera recordings of the same event. Investigators need to know which record is authoritative, how timestamps across systems relate, and what integrity information each exported file can demonstrate.

A live-video integration is therefore not automatically an evidence-management integration. Before production use, the organization still needs to decide which platform serves as the system of record and how aerial footage enters existing retention, export, investigation, and chain-of-custody procedures.

The public documentation does not show that the current integration fails to support those needs. It simply doesn't provide enough information to assume the workflow is complete.

Drone response changes what has to be commissioned

The practical appeal of camera-triggered aerial response is easy to understand. Large industrial properties, logistics yards, substations, and similar sites can cover substantial areas, while a mobile camera can reach viewpoints that fixed surveillance may not provide. Skydio already markets autonomous drone operations for several such environments, although that does not establish a production deployment of the Verkada integration at any particular customer site.

In a real design, the fixed cameras remain the detection layer, and the drone adds mobile observation. The engineering work lies in connecting those layers without treating the integration itself as the whole system.

Alert selection must be deliberate so that every routine motion event doesn't trigger an unnecessary flight request. Camera-location data has to be accurate enough for its new operational role. Aviation authority and launch procedures must be defined, the dock and communications path have to be monitored, and degraded operation needs a fallback when the aircraft cannot respond.

Evidence handling belongs in the same commissioning process. The organization should know where original flight records reside, what transfers into the security platform, what integrity information is preserved, and which system operators to use during an investigation.

These tasks extend familiar physical-security engineering rather than becoming a completely separate discipline. Security designers already validate camera coverage, alarm logic, access-control behavior, network resilience, backup power, and incident procedures. Drone response adds mission planning, geographic accuracy, aviation constraints, aerial communications, aircraft availability, and evidence transfer to that list.

One subtle change is especially important: device-location metadata becomes part of the response logic. A camera's location may previously have mattered mainly for maps and administration. Once that coordinate can influence where an aerial investigation begins, you should test its accuracy and meaning during commissioning.

Verkada and Skydio have connected fixed surveillance to a new type of mobile response. The value is not that a drone somehow replaces the operator or makes an independent threat decision. It gives the operator another way to investigate an event, provided the surrounding architecture is designed with the same care as the cameras themselves.

The engineering lesson is broader than this particular private beta: once a camera alert can request physical action from another autonomous system, location data, authorization, communications, degraded modes, and evidence all become part of the security architecture.

Sources and further reading

Verkada — Drone Integration, September 16, 2026.
Verkada — October 2026 Product Updates, October 2026 release notes; integration entry dated September 16, 2026.
Skydio — Integrate Verkada with Skydio, accessed October 9, 2026.
Skydio — Security Command FAQs, accessed October 9, 2026.
Skydio — Physical Security FAQs, accessed October 9, 2026.
Verkada — Change the Location of a Camera, accessed October 9, 2026.
Verkada — Authenticate Verkada Video Footage, accessed October 9, 2026.
FAA — Part 107 Waivers, accessed October 9, 2026.
Transport Canada — Level 1 Complex Operations, updated March 19, 2026.

AI disclosure: The final prose was generated primarily with AI from a human-reviewed, primary-source-verified technical master.

The Door Is Now an Endpoint: What Gallagher’s ASSA ABLOY Integration Changes

Andrii Slobodskyi — Wed, 07 Oct 2026 17:13:00 +0000

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.

When the Robot Needs a Badge: Physical AI Meets Access Control

Andrii Slobodskyi — Sat, 03 Oct 2026 00:20:00 +0000

An autonomous robot can plan an inspection route, but a route is not permission. When that route reaches a controlled electrical room, the robot needs more than a navigation instruction or a signal to open the door. The facility must recognize the requester, determine whether it is authorized to enter, and allow the physical passage to take place safely.

A recent collaboration between ANYbotics, dormakaba, and LEGIC demonstrates how those requirements can work together. At GE Vernova's Whitegate power station in Ireland, the companies tested a solution that allows the ANYmal inspection robot to pass through an access-controlled door using a digital credential. The pilot involved two automated doors, including a controlled entrance to an electrical room.

For engineers working with robotics, connected infrastructure, and physical security, this is an interesting example of an autonomous machine interacting with a system that was originally designed to control access for people. The robot can pursue its inspection mission, but the facility still decides whether it may enter a protected area.

Why navigation alone cannot complete an inspection route

Industrial inspection robots can follow planned routes, collect measurements, and revisit equipment without requiring a technician to walk through the facility for every inspection. Their usefulness depends partly on how much of the site those routes can cover. A robot may be capable of reaching an equipment room geographically while remaining unable to enter because the door is closed or access-controlled.

Those barriers serve legitimate operational purposes. Doors may protect electrical equipment, separate working areas, or preserve fire compartments. Making a route accessible to an autonomous machine should not require the facility to abandon the functions those doors provide.

ANYbotics describes three previous approaches to the problem: leaving doors open where permitted, deploying separate robots in different areas, or accepting gaps in inspection coverage. Each imposes an operational limitation, whether through restrictions on where doors can remain open, additional robot deployments, or incomplete inspection routes.

The Whitegate project takes a different approach. Instead of designing the inspection mission around an inaccessible doorway, it allows ANYmal to interact with the door infrastructure already installed in the facility. The robot can continue its work when the appropriate access conditions are satisfied, while the entrance remains subject to the site's established rules.

Door automation and access control are separate responsibilities

The collaboration addresses both ordinary automated doors and entrances protected by access control. Although the physical outcome may look identical, the two scenarios require different functions.

At a door without access control, the primary task is coordinating physical movement. The automated door needs to operate in response to the approaching robot, provide a safe passage, and close after the robot has moved through it. ANYbotics and dormakaba have developed this configuration for deployment without introducing an access-authorization requirement where one does not already exist.

A controlled entrance involves an additional layer. The system must establish which robot is requesting entry and determine whether that specific machine may use the door at that time. Simply detecting the robot would not provide the authorization required for entry into a restricted space.

The three partners contribute different parts of this interaction. ANYbotics supplies ANYmal and develops its interaction with the door. LEGIC supplies the digital credential carried by the robot, while dormakaba provides the access-management environment and automated door solution.

These responsibilities remain distinct even when the overall interaction appears seamless. A valid credential does not physically open a door, and an automatic door operator does not establish whether the approaching machine should be admitted. Both functions must be integrated with the robot's ability to recognize when passage is possible.

The implementation also depends on suitable door automation and integration. It should not be understood as a universal zero-touch feature that can be enabled on any existing doorway without additional work.

How the robot's access request is handled

At an equipped access-controlled entrance, ANYmal presents its LEGIC credential to the facility's access-management system. The system verifies the robot's identity and checks whether it is permitted to pass through that particular door at that time.

Once authorization is granted, the automated door confirms that it can operate safely and opens. ANYmal then verifies that the passage is physically open before moving through it. After the robot passes, the door closes and the inspection mission continues.

ANYbotics describes four checks within this interaction: identity, authorization, safe operation, and physical verification. They address related but different requirements, and none can simply be substituted for another.

Identity establishes which machine is requesting access. Authorization determines whether that machine has permission to enter the protected area. The door's safe operation and the robot's verification of the passage address the physical conditions required to complete the movement.

The distinction is particularly relevant to autonomous systems. A successful access decision does not, by itself, establish that the physical environment is ready for the robot to proceed. Likewise, an open doorway does not establish that the robot was authorized to enter.

The denied-access behavior preserves the same separation of responsibilities. According to ANYbotics, if the request is rejected, the door remains secured while the robot reports the issue and adapts its mission. The inspection route does not override the facility's access decision.

Access rights are administered centrally through the existing access-management environment. The partners describe the robot as operating under the facility's established access processes rather than under a separate permission system controlled solely by its navigation software.

There is an important documentation boundary here. The public announcements do not describe the credential transmission protocol, internal access-system data model, or detailed cryptographic implementation. The demonstrated integration supports an architectural explanation of the access process, but not a reconstruction of its undocumented internal mechanisms.

What the Whitegate pilot actually demonstrated

The pilot took place at GE Vernova's Whitegate power station in County Cork, Ireland. Two doors were automated, including an access-controlled entrance to an electrical room. The participating companies reported several weeks of live operation during which ANYmal repeatedly requested access, passed through the controlled entrance, and continued its inspection rounds without manual intervention.

The operational opportunity is easier to understand when considering the inspection work beyond that entrance. In ANYbotics' account of the project, a Whitegate engineer described a room containing approximately 400 readings that had normally been collected by a contractor once a year. With the door-opening solution, the stated intention is for ANYmal to collect those readings daily.

That difference in measurement frequency could provide maintenance teams with a more detailed picture of how equipment conditions develop over time. More frequent observations may also create additional opportunities to identify changes that would be difficult to recognize from infrequent manual inspections.

The distinction between the demonstrated result and the expected benefit is important. The reported live operation establishes that the robot repeatedly passed through the controlled entrance and continued its mission. The proposed daily collection of approximately 400 readings is an intended operational benefit, not a published record of completed daily inspection cycles.

The companies have not published an independent security assessment or quantified cost and defect-detection outcomes for the pilot. Its documented value is the successful integration of autonomous inspection with the facility's access-controlled infrastructure in a live industrial environment.

That result addresses a practical limitation. An inspection robot can reach equipment behind a controlled entrance without requiring the door to remain permanently open or bypassing the facility's authorization process.

Access management becomes part of robot deployment

Introducing an autonomous robot into a facility with protected areas expands the scope of deployment planning. Navigation, inspection sensors, mission configuration, and connectivity remain essential, but the inspection route must also account for the systems that control entry to restricted spaces.

A facility using this approach needs to consider how the robot receives its credential, which entrances it may use, and who administers those permissions. Door automation must also be integrated with the robot's interaction, while mission behavior needs to accommodate a denied access request.

These are engineering implications of the Whitegate integration, not claims about additional undocumented product capabilities.

The collaboration also brings several areas of professional responsibility together. Robot specialists work with navigation and inspection behavior, access-control specialists manage the credential and permission environment, and the door infrastructure must operate safely during the physical passage.

The facility's existing access-management processes provide a common basis for those responsibilities. Rather than giving the robot unrestricted movement to complete its route, the operator can administer its access rights through the same environment used to control entry to protected areas.

This matters as industrial inspection systems become more closely connected to building and security infrastructure. A robot's ability to perform useful work depends not only on its own sensors and navigation capabilities, but also on whether the surrounding facility can accommodate its authorized movements.

The Whitegate pilot shows one way of making that interaction operational. Physical security remains responsible for controlling access, while the autonomous system gains a means of requesting the access its mission requires.

What comes after the first controlled door

ANYbotics says the access-controlled configuration is available on request, with a full rollout planned for 2027. The partners are also exploring future applications involving elevators, gates, and turnstiles.

Those possible extensions should be distinguished from what was demonstrated at Whitegate. The pilot establishes the interaction with automated doors, including an access-controlled entrance. It does not establish completed integrations with every other type of controlled infrastructure, nor does it demonstrate a universal access protocol for autonomous machines.

Nevertheless, the underlying engineering problem is relevant beyond the particular installation. Autonomous equipment working inside real facilities must coexist with physical boundaries, permission rules, and operational processes that were established for legitimate reasons. Greater autonomy does not eliminate those requirements.

The Whitegate project illustrates how a machine can participate in an existing access-management environment while the facility retains the authority to determine where it may go. Digital identity, authorization, door automation, and physical verification work together to support the inspection mission without making movement unrestricted.

The significant development is not that ANYmal can pass through another doorway. It is that an autonomous machine can request entry as an identifiable, authorized participant in the facility's existing infrastructure.

Autonomy becomes more useful when a machine can work within the rules of its environment, rather than requiring those rules to be removed.

Sources and further reading

ANYbotics — Autonomous Door Opening for ANYmal, September 24, 2026.
dormakaba — dormakaba, ANYbotics and LEGIC present a successful pilot of autonomous robots passing through access-controlled doors, September 17, 2026.

AI disclosure: This article was drafted with AI from a human-reviewed, primary-source-verified technical master.

Cisco Meraki + Axis: What Changes When Camera Management Moves Into the Infrastructure Stack

Andrii Slobodskyi — Fri, 25 Sep 2026 16:50:00 +0000

IP cameras have lived on IT networks for years. They consume switch ports, depend on VLANs and PoE budgets, require addressing and upstream connectivity, and ultimately behave like networked edge devices. Yet the camera itself has usually remained inside a separate management environment: a VMS, manufacturer software, or another security-specific toolset.

The Cisco Meraki and Axis integration changes part of that boundary. Supported Axis cameras can now be brought into the Meraki environment for onboarding, health monitoring, firmware management, diagnostics, and, depending on the license tier, parts of the video workflow.

The timing is worth keeping accurate. This integration did not suddenly launch in September 2026: Cisco made the Essentials tier available in April, followed by Advantage in June. The more interesting technical question is what changes when camera lifecycle management begins to appear inside the same cloud platform used to manage the infrastructure around it.

The management boundary is moving

An Axis camera in this architecture is still an IP camera connected through ordinary network infrastructure. What changes is that part of the device-management lifecycle can now be handled through Meraki rather than remaining entirely inside Axis-specific tools or a separate VMS environment.

The integration is built around Axis Cloud Connect. Supported cameras establish their Axis cloud relationship, while Meraki is authorized through a one-time OAuth 2.0 process. Cisco currently documents roughly 90 compatible Axis camera models, primarily devices based on ARTPEC-8, ARTPEC-9, or CV25 platforms. AXIS OS 9.8 is listed as the minimum version, while AXIS OS 11 or later is recommended.

A Cisco switch is not required for the integration itself. When Meraki switching is present, however, it can add automatic discovery and topology context around the camera. That gives the infrastructure platform more awareness of where the endpoint sits in the network without changing the fact that the camera remains an Axis device with its own underlying platform.

A useful conceptual view is:

Axis camera
    |
    +--> Axis Cloud Connect
    |
    +--> Meraki management environment
    |
    +--> Existing video-management environment
         depending on the selected license model

Network infrastructure
    |
    +--> connectivity
    +--> VLANs
    +--> PoE
    +--> topology context when supported
         Meraki switching is present

This is a conceptual management view rather than a packet-flow or video-path diagram. A Meraki application runs on the camera itself, while Axis Cloud Connect remains the underlying device-cloud platform. The architecture therefore gains another management client; it does not simply replace the Axis management layer.

What actually moves into Meraki

The strongest part of the integration is lifecycle management. For supported cameras, Meraki can claim devices, monitor connectivity and health, show firmware status, initiate firmware updates, and provide network-level troubleshooting functions including ping, traceroute, packet capture, remote reboot, and related diagnostics.

Cisco also exposes a documented subset of camera configuration. That includes functions such as zoom, aperture, focus, and PTZ positioning, with additional video and analytics settings available under the higher license tier. This gives an infrastructure-oriented management platform visibility into areas that would traditionally have required a separate security-management workflow.

The boundary is still important. Not every Axis capability has moved into Meraki, and Cisco's own support documentation continues to direct users to the camera's local Axis interface for some diagnostics and camera-specific work. Axis also remains responsible for a number of device-level support questions, so centralized management does not remove the need to understand the underlying camera platform.

That distinction is useful operationally. A team may be able to see camera health, run connectivity tests, initiate an update, or perform certain configuration tasks from Meraki while still needing the Axis interface for work outside the exposed integration surface.

Licensing defines the VMS boundary

The architectural difference between the two license tiers is more significant than a normal feature comparison because the selected tier changes the documented relationship between Meraki and the existing video-management environment.

Essentials: management with VMS coexistence

With Essentials, Meraki provides the management layer around supported Axis cameras and also includes live video. Cisco describes the existing VMS as continuing to operate in parallel, which means an organization can add Meraki-based lifecycle management without requiring the existing video architecture to disappear.

That creates a coexistence model. Meraki becomes another management surface for the camera while the existing VMS remains part of the deployment. From an infrastructure perspective, this separates the question of device lifecycle management from the question of which platform continues to handle the broader video-management workload.

Advantage: the management layer extends further into video

Advantage moves considerably further into the video workflow. Cisco documents historical playback, video export, retention and quality settings, person and vehicle event search, motion-based alerting, heatmaps, and storage options that include local SD recording or Cisco's 30-day cloud storage offering.

Cisco describes Meraki as the "exclusive VMS" when Advantage is used. That wording has architectural significance, but it should not be interpreted more broadly than the available documentation supports. Cisco also warns customers to verify and test existing third-party integrations before moving to Advantage, while the technical mechanism by which the documented "exclusive VMS" behavior is enforced is not publicly described in the material reviewed for this integration.

The safe engineering conclusion is therefore not that every possible third-party interaction is known or understood. It is that the license choice changes the documented VMS relationship, so licensing becomes part of the architecture rather than only a commercial decision.

Commissioning starts to resemble cloud-managed infrastructure

The onboarding model is another area where the camera begins to look more like a managed infrastructure endpoint. Cisco supports pre-staging cameras in Dashboard before they are physically online, allowing a device to be claimed while offline and retrieve its configuration after it connects. In a Meraki-managed network environment, switch discovery can also help identify the camera and provide topology context around where it has been installed.

That workflow is familiar from other cloud-managed infrastructure systems: associate the endpoint with an organization, bring it online, allow the management platform to establish the expected relationship, and then manage part of its lifecycle centrally. For larger deployments, that can reduce some of the friction associated with treating every camera as a completely isolated commissioning task.

It would still be inaccurate to describe the process as universally zero-touch. Depending on the onboarding path, device-side activation steps, Axis credentials, and local access can still be involved, and the local Axis interface remains relevant after deployment. The benefit is therefore centralization of more of the workflow, not the complete elimination of device-level commissioning.

This distinction becomes important during handover. A camera that has been successfully claimed into a cloud-management environment still has local identity, firmware, credentials, network dependencies, and device-specific functions that may need to be documented for the team responsible for long-term operation.

Cloud management creates new trust and operational boundaries

Moving management functions into another cloud platform does not remove architectural dependencies; it changes them. The camera participates in Axis Cloud Connect while Meraki becomes another management client, which means outbound Internet connectivity and the documented firewall requirements become part of the deployment design alongside the normal LAN requirements for the camera.

Firmware is a good example of the resulting operational boundary. Meraki can expose firmware status and initiate updates, and Cisco documents automatic firmware behavior in parts of the integration. The available documentation, however, does not fully describe every firmware-track policy behind that automation, so firmware governance still deserves an explicit operational decision rather than being reduced to an "automatic updates" checkbox.

Access control to the management platform also becomes part of the camera security design. Cisco documents that Meraki Dashboard and the Vision Portal use the same permission model. That can simplify administration, but it also means that the platform's permission structure now influences who can access and manage functions associated with the camera environment.

Traditional camera-system design already has to consider device credentials, VMS permissions, network segmentation, and administrative roles. When lifecycle and video functions extend into a broader cloud-management platform, cloud organization ownership, platform permissions, firmware responsibility, Internet dependencies, and vendor support boundaries all become part of the same design conversation.

Troubleshooting now crosses several management domains

The operational implications become especially clear when something fails. A camera can be reachable at the network layer while the expected application function is unavailable, so "the camera is online" and "the video system is operational" remain two different statements.

Meraki may provide topology information, health data, and network diagnostics. Axis Cloud Connect remains part of the device-cloud relationship, the local Axis interface may still be required for some camera-specific diagnostics, and under Essentials an existing VMS can still be operating in parallel. With Advantage, the documented VMS relationship changes again.

That means troubleshooting ownership should be understood before an outage occurs. A deployment using this model needs clear answers to several practical questions:

Which platform owns onboarding and organization membership?
Who owns firmware policy and update decisions?
Which team controls Meraki and Vision Portal permissions?
Which functions still require access to the local Axis interface?
Which responsibilities remain with Axis support, and which sit with Meraki?
Under the selected license tier, what role does the existing VMS continue to have?
Who owns the incident when connectivity is healthy but the expected application function is not?

These questions are not evidence that the architecture is inherently better or worse. They are a consequence of moving camera lifecycle functions into an additional management domain, and they become particularly important during commissioning, support escalation, and system handover.

The camera is becoming part of the infrastructure lifecycle

The most useful part of the Cisco and Axis integration is not simply that a network-management platform can display or manage a security camera. It is that onboarding, health monitoring, diagnostics, firmware management, permissions, and parts of the video workflow can now exist inside the same broader cloud environment used around other infrastructure.

That changes how the device should be evaluated. Sensor performance, lens selection, analytics, and VMS compatibility remain important, but the camera's management model, cloud relationships, update policy, permission structure, and operational ownership are also part of the architecture surrounding it.

The distinction between IT infrastructure and physical-security infrastructure does not disappear here. Instead, the boundary becomes more interconnected, and the selected management and licensing model determines how much of the camera lifecycle crosses it.

The question is no longer only what does the camera connect to?

It is also which platform manages each part of the camera's life after installation?

Sources and further reading

AI disclosure: The final prose of this article was generated primarily with AI from a human-reviewed, primary-source-verified technical master and was reviewed by the publisher before publication.