The problem with organic infrastructure growth
Large enterprises rarely plan their access control infrastructure from first principles. They acquire buildings, take over facilities from subsidiaries, run security hardware refresh cycles on different timelines at different sites, and make vendor decisions driven by local procurement relationships or available integrators. The result, over a decade or two, is a portfolio of facilities where each site runs a different brand of access control — and each brand runs its own proprietary software console.
This was precisely the situation facing a diversified corporate group managing more than forty facilities across multiple cities. One major campus ran a Honeywell system. A manufacturing plant used HID hardware. A group of acquired buildings still ran a legacy system from a vendor who had been acquired twice since installation. Three more sites ran different mid-tier brands, each with its own card format, event log schema, and management interface.
The consequences were operational rather than theoretical. Security operators required training on multiple consoles and tended to develop deep familiarity with the system at their primary posting while remaining uncertain about the interface at other sites. Cross-site reporting — a simple question like "show me all after-hours entries across all facilities this week" — required extracting data from six different systems, normalising the formats, and assembling a spreadsheet. For the corporate security function trying to maintain a consistent view of access events and alarms across the group, this was untenable.
Card enrolment was equally fragmented. A new employee joining the group required their badge to be provisioned separately in each system that covered the facilities they needed to access. When an employee was terminated, deprovisioning had to happen in each system independently — a process that was error-prone and, on more than one occasion, left active credentials in a system long after the person had departed.
The integration layer
The Teamnet Platform integration layer addressed the heterogeneous hardware problem at the protocol level, not the application level. For vendors who published SDKs — which covered the majority of the installed base — the integration was bidirectional: card data, access level assignments, events, and alarms flowed in both directions between the hardware controllers and the central platform. Provisioning a card in the platform automatically pushed the credential to every relevant hardware system. An alarm event at any controller surfaced immediately in the central console regardless of which vendor's hardware generated it.
For legacy systems without SDK support, the integration used protocol-level communication — reading event logs via the hardware's native interface and normalising them into the platform's unified event schema. These integrations were read-only for event data but could push card data through the vendor's proprietary import mechanism on a scheduled basis.
The normalised data model was the architectural centrepiece. Every event — whether it originated from a Honeywell panel, an HID controller, or a ten-year-old legacy system — was stored with the same fields: site, zone, door, reader direction, card number, person name, timestamp, event type, and alarm status. This normalisation was what made cross-site reporting tractable: the reporting layer had no knowledge of, and no dependency on, the underlying hardware topology.
Facility modelling and physical topology
The platform provided security teams with a self-service facility modelling interface. Before any hardware was connected, the team responsible for a site would define its physical topology in the software:
- Buildings and campuses in the organisational hierarchy
- Floors and zones within each building
- Doors and gates at each zone boundary
- Reader assignments — IN reader, OUT reader, or single reader with direction inference
- Camera assignments — linking CCTV feeds to specific doors for visual verification of access events
Access policies were then defined at the zone level and inherited down to individual doors. A new employee's access level assignment in the central platform automatically resolved to the correct hardware-specific access group at each site they needed to reach, without the administrator needing to understand the underlying hardware structure.
Linking camera feeds to door events was a significant operational improvement for the security control room. When an alarm triggered at a door, the operator's screen automatically displayed the camera feed associated with that door rather than requiring them to navigate to the correct camera in a separate CCTV management system. The reduction in response time for alarm verification was immediate and measurable.
Condition-based notifications and reporting
Beyond real-time monitoring, the platform provided a configurable notification engine. Security managers defined conditions — door held open beyond a threshold duration, after-hours access by a specific category of card holder, repeated failed attempts at a controlled zone, access outside assigned working hours — and mapped each condition to a notification recipient and channel. Condition-based alerting replaced the model where a security operator had to maintain continuous attention on an event stream to catch anomalous patterns.
Scheduled and ad-hoc reports ran against the unified event store. Standard report types covered daily headcount by facility, after-hours access summaries, access anomaly reports, and card activity history by individual. Custom report views could be designed by security administrators without requiring developer involvement, using a point-and-click filter and grouping interface over the normalised event schema.
Results
Following deployment, security operators across all forty-plus sites were trained on a single interface. The training burden dropped substantially, and the quality of monitoring improved because operators could work with confidence at any facility rather than reverting to muscle memory developed on a specific vendor's console. Cross-site reports that previously required manual data extraction from six systems became scheduled exports that arrived in the security manager's inbox each morning. Card enrolment and deprovisioning became single operations with automatic propagation to all relevant hardware systems, eliminating the deprovisioning gaps that had previously been a compliance concern. The corporate security function had, for the first time, a single accurate view of access events and alarm status across the entire facility portfolio.