Smart Building and Campus Surveillance

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you run security for an office, a hospital, a university, or a corporate campus — or you build the software that ties those systems together — the surveillance request you get is almost never "put up some cameras." It is "make the cameras, the doors, the alarms, and the building work as one system, give each tenant its own slice, and let one small team run all of it across every building we own." This article is the vendor-neutral reference design for that job. It walks through what integration really means and the standards that make it possible across mixed-vendor hardware, the choice between a unified platform and a stack of separate systems, how to run one camera-and-door fleet across a whole campus, how multi-tenant access keeps each group inside its own view, and the workplace-privacy line you cross the moment a camera or a door reader starts recognising faces. The goal is that you can scope a build, read a vendor's "fully integrated" claim critically, and avoid the silo-ed install that looks fine in a demo and falls apart during a real incident.

The frame: the building is one system, and the camera is one part of it

Every reference design in this section has a single organising idea, and for a smart building it is this: the camera is not the system. The building is the system, and the cameras, the door locks, the intrusion sensors, the lifts, and the heating are all parts that have to act together. In a retail design the centre of gravity is the analytics; on a perimeter it is early detection; in a city it is scale and privacy law. In a building and on a campus, the centre of gravity is integration — how well the parts talk to each other.

Here is why that reframing matters in money and in minutes. A site can buy excellent cameras, an excellent access-control system, and an excellent alarm system from three different vendors, install all three, and still have a worse security operation than a site with mediocre hardware that is properly joined up. The reason is the human in the control room. When the three systems do not talk, an alarm from one of them is just a noise; the operator has to switch applications, work out which camera covers the event, and find the footage by hand — and every one of those seconds is a second the response is not happening.

So the thing you are really designing is not a camera network. It is a conversation between systems, with a single place a human can watch and act. Hold that test for the rest of the article: every standard, every platform choice, and every campus decision below earns its place only if it makes that conversation faster and clearer.

What "integration" actually means: the door that finds its own camera

Make the idea concrete with the event every integrated building is built around. A door is forced open at 02:14. In a joined-up system, the access-control unit — the controller that decides whether a door opens and records when it does — detects the forced door and emits an event. That event reaches the video management system (the software that records and manages many camera streams, the VMS) which automatically pulls up the camera covering that door, shows the operator the live view and the few seconds of recording just before the alarm, and offers a single button to lock down the surrounding doors. One alarm, one screen, one decision.

Now watch the same event in a siloed building. The access system beeps on one monitor. The operator hears it, turns to the video application on a second monitor, tries to remember the camera number for that door, scrolls a list of four hundred cameras, finds it, then scrubs back through the recording to see what happened — and only then reaches for the access application again to lock the area. The detection was identical. The outcome is not, because the systems never spoke.

Figure 1. The same door-forced event in two buildings. On the left, four separate systems force the operator to switch apps and find the camera by hand. On the right, the access event automatically calls up the right camera and offers a one-click lockdown — one alarm, one screen, one decision. The hardware can be identical; only the integration differs.

This automatic "the door event finds its own camera" behaviour is the heart of what people mean by converged or unified security, and it is the single feature most worth testing before you buy. A useful demand to put to any vendor: show me a live door event automatically calling up the right camera, and show me the unified timeline where the card-read, the video clip, and any analytics flag all line up on one clock. If they can only do it with a custom-coded one-off, it is not really integrated.

The integration map: video, access control, intrusion, and the building

Step back from the single event and look at the whole. A smart-building security system has a small number of subsystems that all need to reach the operator's single pane of glass, and the architecture is best drawn as a hub with spokes. At the centre sits the VMS — or, increasingly, a unified platform that is a VMS and an access-control system and an alarm manager in one product. Around it sit the parts it has to talk to.

The cameras stream video in over ONVIF (more on the profiles in a moment). The access-control system — door controllers, card and mobile readers, electric locks, request-to-exit sensors — reports who opened which door and when, and takes lock and unlock commands back. The intrusion-detection system — motion sensors, door and window contacts, glass-break detectors — reports alarms. The building-management system (the BMS, the controller network that runs heating, ventilation, air-conditioning, lighting, and lifts) exchanges signals: a fire alarm should release locked doors and point cameras at the exits; an after-hours occupancy reading can dim lights and wind down the heating. And the analytics — people counting, loitering, intrusion zones, whose detection models we cover in the AI for Video Engineering section rather than re-derive here — feed events back into the same hub.

Figure 2. The smart-building integration map. The VMS or unified platform is the hub; cameras, access control, intrusion, the building-management system, and analytics are the spokes. The label on each link is the standard that carries it — ONVIF for video and access, OSDP for the readers, BACnet for the building. Integration depth is measured by how many of these links are live and automatic, not by the quality of any single box.

The honest measure of a building's integration is how many of those spokes are live, automatic, and visible in one place — not the spec sheet of any single box. A building where only the cameras are integrated and the access system runs in its own island is a half-built design, and it is the most common one in the field.

The standards that make mixed-vendor integration possible

Integration sounds like it should be a software problem you solve once. The reason it is hard is that the camera, the door reader, the lock, and the air-handling unit are usually made by different companies, and they only cooperate if they share a language. Four standards carry almost all of that conversation, and knowing which one covers which link is most of the battle.

Video rides on ONVIF — the profiles you already know. ONVIF is the industry's common language for IP security devices; for cameras it is Profile S (live streaming) and Profile T (advanced streaming, including H.265 and analytics-friendly features), with Profile G for recording. We cover these in depth in ONVIF explained for engineers and which ONVIF profile your product needs, and there is a commercial overview in ONVIF profiles in security systems.

Access control rides on ONVIF too — but different profiles, and this is the trap. Most people hear "ONVIF" and think cameras. ONVIF also standardises access control, through three profiles that did not exist when ONVIF began. Profile C (released December 2013) was the first; it standardises basic door control and the events and alarms around a door — locked, unlocked, forced, held — and, paired with the video profiles, gave the industry its first common interface joining access control and video. Profile A (released June 2017) goes up a level to configuration and policy: creating and revoking credentials, setting schedules, and defining who may go through which door. Profile D (released June 2021) goes down a level to the peripherals — the locks, the card and PIN and biometric readers, the door phones and sensors hanging off a door controller; a Profile D reader captures a credential and hands it to the controller, which holds the rules and makes the decision. ONVIF's own guidance is explicit that "access control systems can make use of Profiles A, C, D, and M."

The reader-to-controller link rides on OSDP. Below the access controller, the cable running to each card reader has its own standard. For decades that was Wiegand, a one-way protocol from the 1980s with no encryption and no supervision — a reader could be unplugged or spoofed and the controller would never know. The modern replacement is OSDP (Open Supervised Device Protocol), the Security Industry Association's standard, approved internationally as IEC 60839-11-5 in 2020. OSDP is two-way and supervised (the controller knows instantly if a reader goes offline), runs over a two-wire RS-485 bus, and its Secure Channel adds encryption and authentication so the reader and controller cannot be impersonated. Specifying OSDP with Secure Channel rather than Wiegand is one of the cheapest security upgrades in the whole building.

The building systems ride on BACnet. Heating, ventilation, lighting, and lifts almost always speak BACnet, published as ASHRAE Standard 135 and internationally as ISO 16484-5. BACnet's scope explicitly includes HVAC, lighting, lift, security, and fire systems, which is what lets a security platform exchange signals with the building: release doors on a fire alarm, or let an occupancy count from the cameras tell the BMS to wind the heating down.

Figure 3. The standards that carry each link, and the boundary where you still need a vendor SDK. ONVIF Profiles S/T/G carry video; Profiles A, C, and D carry access configuration, door events, and reader peripherals; Profile M carries analytics metadata; OSDP carries the reader-to-controller link; BACnet carries the building systems. As with cameras, a profile guarantees a baseline — deep, vendor-specific features still ride on an SDK.

One caution carries over from everything we say about ONVIF and cameras: a profile guarantees a baseline, not full feature parity. Two Profile A systems will exchange credentials and schedules, but a vendor's richest features — a specific anti-passback rule, a proprietary mobile credential, an unusual lockdown workflow — often still need that vendor's software development kit (SDK). "ONVIF-conformant" means the baseline interoperates; it does not mean every feature crosses the brand boundary. Plan integrations to the profile, and budget SDK work for anything beyond it. ONVIF is also clear that conforming to a profile is a baseline for interoperability and that regulatory compliance and the right cybersecurity level for the use case remain the integrator's responsibility, not something the standard certifies.

The access-and-video event flow, drawn out

Put the standards into motion on the canonical event. A person presents a badge at a door; the OSDP reader passes the credential to the access controller over its encrypted link; the controller checks its rules — is this credential valid, at this door, at this time — and either unlocks the door or denies it, recording the decision. That decision is an event. Through ONVIF Profile C, the event reaches the unified platform or VMS, which ties it to the camera covering that door and stamps it on a shared timeline alongside the video. If analytics are running on the camera, their metadata arrives over ONVIF Profile M, so a "person loitering at the door" flag and the "door forced" event sit on the same clock. The operator sees one correlated picture; a forced-door or after-hours event can trigger an automatic camera call-up, a recording bookmark, and a one-click lockdown that the platform sends back down through Profile C and the controller.

Figure 4. The badge-to-screen path. The OSDP reader hands the credential to the controller; the controller decides and emits an event; ONVIF Profile C carries the door event and Profile M the analytics metadata to the platform, which correlates them with the camera on one timeline and can send a lockdown command back. The orange branch is the legal gate: the moment a reader or camera identifies a person by face or fingerprint, biometric-privacy law applies before the feature ships.

There is one branch on that diagram drawn in warning colour, and it is the most important line in this article for a lawyer to read. The moment the credential is a biometric — a face at the camera, a fingerprint or face at the reader — the system is processing data that uniquely identifies a person, and that crosses from a security-engineering decision into a legal one. We come back to it under privacy below; flag it here so it is never an afterthought wired in late.

Multi-tenant: one physical system, many private views

A campus or a commercial building rarely has one audience. An office tower has several tenant companies; a hospital has departments that must not see each other's wards; a university has faculties, residences, and a central security office; a managed building has a landlord and many leaseholders. They share one physical camera-and-door system, but each must see only its own slice — and must not see anyone else's.

The mechanism is logical partitioning with role-based access control (RBAC) — the rule that what you can see and do in the software is decided by your role, not by your individual login. One physical system is divided into partitions, one per tenant or department; a tenant's operators are bound to their partition and simply cannot open another tenant's cameras, doors, or recordings. The landlord or central security team holds a cross-partition role for the shared spaces — lobbies, car parks, perimeters — and for emergencies. This is the same discipline a city uses to keep agencies inside their lane, applied at building scale; we treat the federated, multi-agency version in city and public-space surveillance.

Two pitfalls live here. The first is treating partitioning as a viewing convenience rather than a hard data boundary: in a multi-tenant building it is often a contractual and legal requirement that one tenant's footage is inaccessible to another, so the partition has to be enforced in the platform's permission model and audit log, not merely hidden in the interface. The second is forgetting the shared spaces: a lobby camera that three tenants all need to see, and that the landlord owns, needs a deliberate home in the model rather than being duplicated or argued over after go-live.

The campus problem: many buildings, one fleet

A single building is hard enough. A campus multiplies it: many buildings, sometimes many sites, that the organisation wants to run as one system with one operator team — while keeping each building's recording and bandwidth local. The pattern that solves this is federation: each building records and runs its analytics on local servers or appliances, and a campus-level management layer presents all of them as one searchable system, pulling live or recorded video across the network only when an operator actually asks for it. Centralising every stream to one data centre is the design that does not scale — it turns the campus backbone into a constant firehose and makes that data centre a single point of failure. We derive the record-local, stream-on-demand pattern in federation: managing many sites as one.

Put rough numbers on why centralising fails. Suppose a campus has 400 cameras averaging 2 Mbps each.

Stream every camera to one central data centre, always-on:
  400 cameras × 2 Mbps        = 800 Mbps of constant backbone traffic
  → a permanent firehose, plus one data centre as a single point of failure

Record locally, pull on demand (say 30 live views at peak):
  30 streams × 2 Mbps         = 60 Mbps when an operator is actually watching
  → ~92% less backbone traffic, and each building survives a network cut

The numbers are illustrative and move with resolution, codec, and how many views are open, but the shape is stable: record where the camera is, move video only when a human needs it. The same logic decides where analytics run — at the edge, on or near the camera, for speed and to avoid shipping raw video around, which is the building face of the edge vs cloud video analytics decision.

The second half of the campus problem is fleet management: hundreds or thousands of cameras and door devices that all need onboarding, firmware updates, certificate rotation, password management, and health monitoring. At ten cameras this is manual housekeeping; at a thousand it is a system in its own right, and skipping it is how a campus ends up with cameras three firmware versions behind and a third of them quietly offline. Plan the discovery-and-onboarding pipeline and the health dashboard as first-class parts of the design — we cover them in camera discovery and onboarding at scale and the capacity side in scaling a VMS: capacity planning.

Figure 5. A campus as one federated, partitioned system. Each building records locally and runs analytics at the edge; a campus management layer presents the whole estate as one system and streams video only on demand. Tenant and department partitions (role-based access control) run across the buildings, so each group sees its own cameras while the central team holds the shared spaces.

The building-specific analytic: occupancy and space utilisation

Most analytics in this section — detection, tracking, recognition — are about security. Buildings add one that is mostly about operations: counting how many people are in a space and how that space gets used. The same people-counting analytic that a shop uses to measure queues lets a building measure occupancy: how full is each floor, which meeting rooms sit empty, when does the canteen peak. Fed to the BMS over BACnet, that count drives real savings — dimming lights and winding down heating in empty zones — and feeds the space-planning decisions that matter when offices run at barely half their capacity on an average day. The people-counting mechanism itself is the one from retail analytics: people-counting and heatmaps; here it points at the building instead of the shopper.

This is also where an honest design makes a privacy choice early. Occupancy needs a count, not an identity — how many people, not who. A well-built occupancy analytic counts anonymously and keeps no recognisable image, which keeps it well clear of biometric law and is far easier to defend to staff and a regulator. And cameras are not the only way to count: Wi-Fi and Bluetooth presence, simple infrared people-counters at doorways, and desk sensors all measure occupancy without a camera at all, and are often the better, lighter choice where the only goal is utilisation. Use a camera for occupancy when you are already recording the space for security and the count is a by-product — not as a reason to point a new camera at people's desks. Never quietly repurpose security footage into individual productivity monitoring; that is a fast route to losing the workforce's trust and crossing the workplace-privacy line below.

Cybersecurity: every camera and reader is a device on the building network

A smart building turns hundreds of cameras and door devices into computers on a shared network, and each one is a potential way in. This is not a footnote; in a connected building it is part of the architecture. Three habits carry most of the weight.

First, segment the network. Cameras, access controllers, and building systems belong on their own isolated network segments (VLANs), separated from the corporate network and the internet, so that a compromised camera cannot reach the finance server and an attacker on the office Wi-Fi cannot reach the cameras. Second, close the obvious doors: change every default password, rotate device certificates, keep firmware current across the fleet (which is why fleet management above is a security control, not just housekeeping), and use OSDP Secure Channel rather than Wiegand so a reader cannot be spoofed at the wall.

Third, mind where the hardware comes from. For many buildings — anything touching US federal funding, and a growing list of states, universities, and prime contractors — procurement is constrained by Section 889 of the 2019 US National Defense Authorization Act, which bars federal agencies and their contractors and grant recipients from buying video-surveillance equipment from named manufacturers (Hikvision, Dahua, and Hytera, alongside Huawei and ZTE), implemented through the Federal Acquisition Regulation (FAR 52.204-25). Even where it does not bind you legally, the named-vendor question now shows up in enterprise and campus procurement as a default screen. Confirm the supply-chain constraints that apply to your building before you choose hardware, not after.

A worked example: a corporate campus

Put the pieces on one site. Take a corporate or university campus: six buildings, around 400 cameras, around 200 doors, three tenant groups plus a central security team, recorded for 30 days.

Integration plan (one unified platform OR a VMS + access system joined by standards):
  Video        cameras over ONVIF Profile S / T (+ G for recording)
  Access       door controllers over ONVIF Profile C (events) + Profile A (config)
  Readers      OSDP with Secure Channel to every reader  (not Wiegand)
  Building     BACnet link to HVAC / lighting / lifts / fire
  Analytics    edge people-counting + after-hours intrusion, events over Profile M

Federation (record local, stream on demand):
  6 buildings × local recording + edge analytics
  Backbone at peak: ~30 live views × 2 Mbps  ≈  60 Mbps   (not 800 Mbps always-on)

Multi-tenant:
  3 tenant partitions + 1 central role for shared spaces (lobbies, car parks)
  RBAC enforced in the permission model and the audit log, not just the UI

Privacy gate (before go-live):
  Workplace-monitoring basis documented; notice / signage posted
  Occupancy analytics anonymous (count, not identity)
  Any face / fingerprint at a door held behind a deliberate legal review

Every number here is illustrative and moves with the real building — size a true design with our surveillance cost model and the smart-building & campus integration checklist below, which puts the integration map, the standards to specify, the multi-tenant plan, the fleet-management list, the cybersecurity steps, and the privacy gate on a single page. The shape of the design, though, is stable: integrate the subsystems through the right standards, federate the campus so recording stays local, partition the system per tenant, run occupancy anonymously, and treat the network and the supply chain as security controls.

The privacy line for buildings and campuses

Buildings and campuses watch a particular kind of person: employees, students, patients, and visitors who are there every day, often with little choice about being recorded. That raises the privacy stakes in two specific ways, and both belong in the architecture, not in a late compliance scramble.

The first is workplace and continuous monitoring. Under the EU's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679), filming staff and visitors is processing personal data, and it usually rests on the legitimate-interest basis (Article 6(1)(f)) with a documented necessity-and-proportionality test — you have to show the cameras serve a real security purpose and are aimed no wider than needed. GDPR Article 88 specifically lets member states add stricter rules for monitoring in the employment context, and the European Data Protection Board's Guidelines 3/2019 on video devices set out how this applies to cameras; many jurisdictions also require informing or consulting staff before monitoring begins. Practically: post clear notice and signage, keep cameras out of private spaces (toilets, changing rooms, prayer rooms), set retention to the minimum you need (GDPR Article 5(1)(e)), and where the monitoring is systematic and large-scale, complete a Data Protection Impact Assessment (Article 35). We go deeper in GDPR for video surveillance, privacy by design for surveillance, and consent and notice for surveillance.

The second is the biometric gate at the door and the camera — the orange branch from the event-flow diagram. A face-recognition camera or a fingerprint or face reader processes biometric data that uniquely identifies a person, which GDPR Article 9 treats as a special category with a higher bar, and which several US states regulate sharply — most notably Illinois, whose Biometric Information Privacy Act (BIPA, 740 ILCS 14) carries a private right of action and statutory damages that have produced very large settlements. Convenience features like "let staff in with their face" are not free toggles; they are a deliberate decision that needs a lawful basis, often explicit consent, and counsel's sign-off before they ship. Route any face or fingerprint workflow through face recognition in surveillance and BIPA and US biometric privacy law — with a lawyer, not a default setting.

Where Fora Soft fits in

Fora Soft has built video streaming, real-time video, and computer-vision software since 2005, across 625+ projects, and smart-building and campus systems sit right where our surveillance, computer-vision, and integration work meet. When we build or join up a building or campus system, we lead with how it behaves as one system under real load — whether the door event actually finds its camera in under a second, what the campus backbone truly carries once recording is federated, whether the multi-tenant partition holds in the audit log and not just the screen — and only then the feature list, because an integration that demos well and falls apart in an incident protects nobody. We treat the standards boundary (where ONVIF and OSDP and BACnet stop and an SDK begins), the network segmentation, and the workplace-privacy line as architecture decisions made early, so the system survives both a busy Monday and a regulator's question.

What to read next

• Industrial and critical-infrastructure surveillance — the high-reliability reference design next door.
• Federation: managing many sites as one — the campus pattern in depth.
• Estimating a surveillance project: scope to number — turn this design into a cost.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your smart building surveillance plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Smart Building & Campus Integration Checklist — One-page planning tool for a smart-building or campus surveillance build: the integration map (what must reach the operator's single pane of glass — cameras, access control, intrusion, building systems, analytics); the standards to….

References

1. ONVIF Profile C (released December 2013). ONVIF. Tier 1. The first ONVIF access-control profile — standardises basic door control and door events/alarms; with the video profiles, the first common interface joining access control and video surveillance. https://www.onvif.org/profiles/onvif-profile-c/
2. ONVIF Profile A (released June 2017). ONVIF. Tier 1. Standardises access-control configuration and policy — credentials, schedules, and access rules — across multi-vendor access systems. https://www.onvif.org/profiles/onvif-profile-a/
3. ONVIF Profile D (released June 2021). ONVIF. Tier 1. Standardises access-control peripherals — locks, card/PIN/biometric readers, door phones, sensors, displays; the peripheral captures the credential and the controller makes the decision. Complements Profiles A and C. https://www.onvif.org/profiles/profile-d/
4. ONVIF Profiles overview ("Access control systems can make use of Profiles A, C, D, and M"). ONVIF. Tier 1. Confirms the profile-to-link mapping and that conformance is a baseline; regulatory compliance and the right cybersecurity level remain the integrator's responsibility. https://www.onvif.org/profiles/
5. Open Supervised Device Protocol (OSDP), SIA standard; adopted as IEC 60839-11-5 (2020); SIA OSDP v2.2.2 (Oct 2024). Security Industry Association. Tier 1/2. The two-way, supervised, RS-485 reader-to-controller protocol with Secure Channel encryption that replaces the one-way, unencrypted Wiegand. https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/
6. BACnet — ANSI/ASHRAE Standard 135 / ISO 16484-5. ASHRAE / ISO. Tier 1. The building-automation data-communication protocol; scope covers HVAC, lighting, lifts, security, and fire — the standard that lets a security platform exchange signals with the building. https://www.ashrae.org/technical-resources/bookstore/bacnet
7. General Data Protection Regulation (Regulation (EU) 2016/679), Art. 6(1)(f), Art. 9, Art. 35, Art. 88, Art. 5(1)(e). European Union (EUR-Lex). Tier 1. Legitimate-interest basis for workplace monitoring; biometric data as special category; the DPIA trigger; member-state employment-context rules; storage limitation. https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. Guidelines 3/2019 on processing of personal data through video devices (v2.0, 2020). European Data Protection Board. Tier 2. How GDPR applies to video devices — legitimate-interest necessity/proportionality, data minimisation, retention, and the special treatment of biometric data. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en
9. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14. State of Illinois. Tier 1. Regulates capture and storage of biometric identifiers (including face and fingerprint); private right of action and statutory damages — the controlling source for the door/camera biometric gate in Illinois. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004
10. Section 889 of the 2019 National Defense Authorization Act; FAR 52.204-25. US Government. Tier 1. Bars federal agencies, contractors, and grant recipients from procuring video-surveillance equipment from named manufacturers (Hikvision, Dahua, Hytera, Huawei, ZTE) — the supply-chain screen for many campuses. https://www.acquisition.gov/far/52.204-25
11. IEC 62676: Video surveillance systems for use in security applications. IEC. Tier 1. The video-surveillance systems standard family (including Part 4 application guidelines / DORI) used to specify cameras and recording in the design. https://webstore.iec.ch/publication/28442
12. Security Center: unified security platform (access control, video, ALPR, intrusion in one pane of glass); Omdia world #1 VMS software 2025. Genetec / Omdia. Tier 4/5. Engineering description of converged video-and-access — badge-in automatically showing the door camera, the unified timeline — used as the "what actually ships" reference for the unified-platform pattern, not as a standards source. https://www.genetec.com/products/unified-security/security-center