Security Systems Infrastructure Engineering: Networks, Servers, Power, UPS and Resilience

Cameras, readers and alarms are the visible parts of a modern security system.

Behind them is another system that is just as important:

network → switches → fibre → servers → storage → databases → power → UPS → time services → remote access → monitoring

If that infrastructure is poorly designed, perfectly good field devices can become unreliable.

A camera may be working but unable to reach the recorder.

A reader may be online but unable to communicate with its controller.

An NVR may have backup power while the PoE switches supplying every camera shut down immediately.

A server may be redundant while both servers depend on the same network switch.

A project may provide a 1 Gbps uplink even though the calculated camera traffic is already close to that capacity.

This is why security-system infrastructure needs to be engineered as part of the security design rather than treated as an IT detail to be resolved after installation.

The fundamental question is:

What infrastructure must remain available for the security function to continue operating?

1. Start with the security-system architecture

Before calculating bandwidth or choosing switches, map the complete system.

A typical IP video surveillance architecture might look like:

IP CAMERAS

    |

    v

ACCESS SWITCHES / PoE

    |

    v

DISTRIBUTION NETWORK

    |

    v

SECURITY CORE

    |

    +—— VMS / NVR

    |

    +—— STORAGE

    |

    +—— CCTV WORKSTATIONS

    |

    +—— INTEGRATION SERVER

Access control may use a different architecture:

READERS / LOCKS / CONTACTS

          |

          v

   DOOR CONTROLLERS

          |

          v

   SECURITY NETWORK

          |

          v

    ACS APPLICATION

          |

     DATABASE / VM

          |

   OPERATOR WORKSTATION

And intrusion detection may connect through:

SENSORS

   |

   v

ALARM PANEL / INPUT MODULES

   |

   v

SECURITY NETWORK

   |

   v

MONITORING / INTEGRATION PLATFORM

The first engineering task is therefore to identify:

What talks to what?

Then:

What happens if any one part disappears?

2. Separate field-device architecture from management architecture

It is useful to think of security systems as having two layers.

Field layer

This includes:

cameras, readers, locks, door contacts, sensors, intercoms, controllers and PoE switches.

Management layer

This includes:

VMS, NVRs, ACS servers, databases, alarm servers, integration platforms and operator workstations.

A failure at the management layer should not necessarily mean every field device immediately stops performing its local function.

For example, depending on the platform, an access-control controller may continue validating credentials even if the central server is offline.

Likewise, cameras may continue edge recording during a network interruption if that capability has been designed and configured.

Understanding what operates locally and what depends on central infrastructure is essential for resilience planning.

3. Decide whether security shares the corporate network

There is no universal answer.

Some organisations place physical-security systems on the corporate network.

Others use:

dedicated VLANs, dedicated switching infrastructure or completely separate networks.

The design should consider:

security risk, cybersecurity policy, IT governance, availability requirements, administrative responsibility and cost.

A useful distinction is between:

logical separation

and

physical separation.

A dedicated VLAN provides logical separation.

Separate switches, fibre and core infrastructure provide physical separation.

The second creates stronger independence, but at additional cost and operational complexity.

4. A VLAN is not the same as a separate network

This distinction matters.

Suppose CCTV is on:

VLAN 120

and access control is on:

VLAN 130.

They may still pass through the same:

physical switches, uplinks, core infrastructure and power supplies.

If the shared core switch fails, both systems may disappear simultaneously.

Therefore:

VLAN separation controls traffic. It does not automatically provide infrastructure resilience.

The designer should distinguish:

cyber/network segmentation

from

failure-domain separation.

5. When might CCTV be separated from access control?

CCTV typically generates large volumes of continuous traffic.

Access control normally generates relatively low bandwidth but may have different cybersecurity and business-continuity requirements.

Separating the two can reduce the chance that:

high CCTV traffic, network storms or video-related changes

affect access-control communications.

It can also make firewall policies and troubleshooting clearer.

A typical enterprise arrangement might use:

CCTV VLAN

ACS VLAN

INTERCOM VLAN

SECURITY MANAGEMENT VLAN

with tightly controlled communication between them.

The exact architecture depends on the organisation.

6. Design IP addressing before installation

A security project should not reach commissioning with:

“We’ll just give every device whatever IP address is available.”

A structured IP plan helps with:

device identification, troubleshooting, firewall rules and expansion.

For example:

These addresses are illustrative only.

The important point is that the structure is planned.

7. Static IP or DHCP?

Many security systems use static addressing for infrastructure devices because predictable addresses simplify:

device management, firewalling, VMS configuration and troubleshooting.

Another approach is:

DHCP reservations

where the organisation centrally controls device addressing through the DHCP service.

Either can work.

The important requirement is predictability and documentation.

A camera unexpectedly receiving a new address should not break recording.

8. Do not underestimate switch-port requirements

A switch should not be sized using only:

current camera count.

Consider:

camera ports, uplinks, spare ports, management connections, intercom devices and future additions.

If a floor currently needs:

38 cameras

then specifying a 48-port switch leaves:

10 nominal spare ports.

But if two or four ports are required for uplinks, stacking or other infrastructure, the true spare count is lower.

Capacity should therefore be based on:

usable ports, not the model number printed on the switch.

9. PoE port count and PoE power budget are different things

This is one of the most common CCTV infrastructure mistakes.

A 48-port PoE switch may have:

48 PoE-capable ports

but that does not mean it can necessarily deliver maximum PoE power to all 48 simultaneously.

The switch has a total PoE budget.

Suppose:

48 cameras × 12 W average maximum design draw

48×12W=576W

If the switch provides only:

370 W PoE budget

then it cannot support the theoretical full design load.

Port count is sufficient.

Power is not.

10. Calculate PoE using worst-case or design consumption

Camera datasheets may show different power values depending on:

IR illumination, heater, PTZ movement, analytics, accessories or PoE mode.

For design, do not use only the lowest typical consumption figure.

For example:

Camera normal operation:

7 W

Camera with IR active:

12 W

If all cameras turn on IR after dark, the switch may suddenly experience a much higher simultaneous load.

A better design uses:

appropriate maximum or design consumption

for PoE budgeting.

11. Example PoE calculation

Assume one floor has:

Total:

30×10=300W8×15=120W2×30=60W

Total PoE requirement:

300+120+60=480W

If the proposed switch provides a:

740 W PoE budget

then the design has reasonable headroom.

If it provides:

370 W

the design is inadequate even though there are enough physical ports.

12. PoE standards matter

Different powered devices may require:

PoE, PoE+ or higher-power variants.

The security designer should therefore verify:

device standard, required wattage, switch support and total budget.

A high-power PTZ, intercom or door station may consume far more than an ordinary fixed camera.

One unusual device can therefore materially affect switch design.

13. CCTV bandwidth should be calculated, not guessed

A basic CCTV recording-bandwidth estimate is:

Total Camera Traffic=Number of Cameras×Average Bitrate

Assume:

64 cameras

at:

4 Mbps average stream bitrate

Then:

64×4Mbps=256Mbps

So approximately:

256 Mbps

of continuous camera recording traffic must reach the recorder.

That does not yet include:

live viewing, playback, secondary streams, analytics, retransmission or protocol overhead.

14. Do not automatically use average bitrate as peak bandwidth

Average bitrate is useful for storage estimation.

Network design also needs to consider:

peak behaviour.

Variable-bitrate cameras may temporarily exceed the average when:

movement increases, lighting changes, rain occurs or scene complexity rises.

A network should therefore not be engineered so close to its theoretical capacity that normal bitrate variation causes congestion.

15. Avoid designing uplinks to 95% utilisation

Suppose the calculated expected camera load is:

850 Mbps.

A 1 Gbps uplink might look acceptable because 850 is less than 1,000.

But this leaves very little practical headroom for:

traffic bursts, management overhead, live viewing, retransmission or future cameras.

The theoretical line speed is not the same as a good engineering target.

Where CCTV traffic is large, uplink design should provide meaningful spare capacity.

16. Think about traffic direction

Most camera traffic flows:

camera → recorder

but not all CCTV traffic follows that path.

Additional flows may include:

camera → analytics server

recorder → workstation

recorder → archive storage

recorder → remote client

camera → secondary monitoring system

Therefore a network diagram should show:

actual data paths

rather than merely switch connections.

17. Secondary streams can reduce unnecessary load

Many CCTV platforms support:

high-resolution primary streams

and

lower-bandwidth secondary streams.

The high-quality stream may be used for:

recording.

A lower stream may be used for:

multi-camera viewing.

This can reduce workstation and network demand.

But the configuration must still preserve the required image quality where it matters.

18. Video analytics may change the network architecture

Analytics may run:

at the camera

or

on a central analytics server.

If analytics runs centrally, camera streams may need to travel to:

both the recorder

and

analytics infrastructure.

That can materially increase network traffic.

Therefore the security designer should know where the processing occurs.

19. Copper or fibre?

Copper Ethernet is useful for field-device connections where distance and environment allow it.

Fibre is commonly used for:

floor uplinks, building backbones, long distances and electrically challenging environments.

Security designs often use:

camera → copper → access switch → fibre → core

This reduces long copper runs while providing a higher-capacity backbone.

20. Respect Ethernet distance limits

Standard copper Ethernet runs have practical distance limitations.

A project should not simply route a camera hundreds of metres back to a central switch because:

“It is still Cat6.”

Where distance becomes excessive, the design may require:

local switches, fibre or appropriate transmission equipment.

Long-distance design should be resolved during infrastructure planning rather than after cable installation.

21. Fibre topology affects resilience

One common topology is:

CORE

 |

 +—- Floor 1 Switch

 |

 +—- Floor 2 Switch

 |

 +—- Floor 3 Switch

Each floor has an independent uplink.

Another is a daisy chain:

CORE

 |

Floor 1

 |

Floor 2

 |

Floor 3

The daisy chain may reduce fibre requirements.

But if the Floor 1 switch or link fails, Floors 2 and 3 may also disappear.

The topology therefore creates a larger failure domain.

22. Star topology versus ring topology

A star gives each access/distribution switch a direct path to the core.

A ring can provide alternate paths when properly implemented with suitable switching protocols.

Neither is automatically correct for every project.

The important question is:

What happens if one fibre or one switch fails?

The topology should answer that question deliberately.

23. Do not create accidental single points of failure

Common hidden single points of failure include:

• one core switch;
• one fibre uplink;
• one recorder;
• one storage array;
• one power supply;
• one UPS;
• one network rack;
• one server host;
• one database;
• one WAN link.

A design can look highly redundant on a schematic while all “redundant” systems depend on the same underlying component.

24. Redundancy needs independence

Suppose a project has:

Server A

and

Server B

and calls the design redundant.

But both servers are:

in the same rack, on the same power circuit, connected to the same switch and hosted on the same virtualisation platform.

A failure of:

the rack power, core switch or virtualisation host

can still remove both.

This is not necessarily wrong.

But the actual resilience should be understood honestly.

25. Define the required resilience level

Not every system needs full high-availability architecture.

A small office may accept:

one recorder and one switch per floor.

A critical facility may require:

dual network paths, redundant servers, separate storage, alternate power and geographically separated systems.

Resilience should be proportional to:

risk, operational consequence and recovery expectations.

Otherwise the project either:

under-engineers important security systems

or

spends heavily on redundancy that provides little practical benefit.

26. Security servers can be physical or virtual

Modern security platforms may run on:

dedicated physical servers

or

virtual machines.

Virtualisation can provide advantages such as:

hardware consolidation, simpler backup, easier resource allocation and platform redundancy.

But it creates dependencies on:

the hypervisor, shared storage, virtual networking and the organisation’s IT infrastructure.

The security designer therefore needs to understand what the VM actually depends on.

27. “The server is virtual” does not mean infrastructure disappears

A security integrator may specify:

ACS server to be provided as VM by client.

That does not remove server engineering.

You still need requirements for:

CPU, RAM, storage, operating system, database, network interfaces, backup, recovery, time synchronisation and cybersecurity.

Virtual infrastructure still needs physical resources underneath it.

28. Separate application and database requirements

Access-control and integrated-security platforms may require:

application services

and

database services.

Depending on the system, these may exist:

on one server

or

on separate servers.

The design should identify:

what database engine is required, who provides licensing, backup responsibilities, recovery requirements and connectivity.

If this is left unresolved until commissioning, it often becomes a project delay.

29. Storage traffic may require special consideration

Large VMS deployments may use:

direct-attached storage, NAS, SAN or vendor-specific distributed storage.

The recording network may therefore carry substantial traffic between:

recording servers and storage.

This traffic can be separate from:

camera ingestion traffic.

A large system may therefore need more than one simple “security LAN”.

30. Time synchronisation is critical

Every major security component should have consistent time.

Imagine an incident where:

CCTV says 14:03:18

access control says 14:05:41

intrusion system says 14:02:57.

Correlating events becomes difficult.

Security systems should therefore use a reliable common time source.

NTP is commonly used.

The exact architecture depends on the organisation’s IT policies.

31. Time errors can become investigation errors

A security system may be technically healthy yet produce misleading incident chronology if its clocks drift.

This is especially serious when reviewing:

access events, CCTV footage, alarm activations and intercom calls.

Time synchronisation should therefore be commissioned, monitored and periodically checked.

32. DNS may matter more than expected

Some security platforms use:

hostnames, cloud services, certificate validation, software licensing or other functions

that depend on DNS.

If DNS is unavailable, the device may appear to have “internet” or network connectivity while particular functions fail.

Network requirements should therefore identify whether the system relies on:

IP only

or

DNS services.

33. Firewall requirements should be documented

Do not solve security-system connectivity by asking IT to:

“Open everything between the VLANs.”

Instead document:

source

destination

protocol

port

direction

purpose

For example:

The actual ports are system-specific.

The structure should be standardised.

34. Segmentation improves cybersecurity and troubleshooting

Separating security devices into defined segments can reduce:

unnecessary communication, broadcast domains and exposure.

It also makes troubleshooting easier.

For example:

If all cameras are in one documented segment, a connectivity issue becomes easier to isolate than when cameras are scattered randomly across the corporate LAN.

35. Do not expose cameras directly to the Internet

Direct Internet exposure creates unnecessary risk.

Remote access should generally occur through controlled infrastructure such as:

VPN, authorised secure gateways or properly designed cloud architectures.

The exact method depends on the manufacturer’s architecture and client cybersecurity requirements.

The engineering principle is:

Remote convenience should not bypass network security.

36. Default passwords must never survive handover

Security infrastructure should not leave site with:

default device accounts or shared installer credentials.

Commissioning should include:

account review, credential changes, permissions and handover responsibility.

This is especially important for:

cameras, NVRs, switches, controllers, intercoms and management servers.

37. Principle of least privilege applies to security systems too

An operator who needs to:

view cameras

does not automatically need permission to:

change recorder configuration.

A facilities technician who needs to:

acknowledge equipment faults

may not need:

user-management privileges.

Role design should match operational responsibilities.

38. Power design starts with the entire security chain

A system remains available only while all required components remain powered.

For CCTV, that may mean:

camera + PoE switch + fibre equipment + core switch + NVR/VMS + storage + operator workstation

For access control:

reader + controller + lock power + network + ACS server

The system should therefore be analysed as an end-to-end electrical dependency.

39. Do not only back up the recorder

This is an extremely common mistake.

The NVR receives:

30 minutes of UPS.

But the PoE switch supplying the cameras has:

no backup.

During a blackout:

NVR stays online.

Cameras disappear.

The recorder is successfully recording:

nothing.

UPS design must consider the whole required operating path.

40. Calculate the security power load

Suppose a security rack contains:

Total:

500+500+150+350+450+300+250=2,500W

So the approximate design load is:

2.5 kW

That is the starting point for UPS sizing.

41. UPS VA rating and watt rating are not the same thing

UPS systems may be described in:

VA

and

W.

Power factor affects the relationship.

A UPS labelled:

3 kVA

does not automatically mean it can provide:

3 kW.

The design should check the manufacturer’s actual watt rating.

42. UPS runtime depends on more than the headline size

A UPS rating tells you how much load it can support.

It does not directly tell you how long it will support it.

Runtime depends on:

battery capacity, load, UPS efficiency, battery age and environmental conditions.

A 5 kVA UPS supporting a 1 kW load will typically last longer than the same UPS supporting 4 kW.

Therefore UPS design requires both:

capacity

and

runtime.

43. Example UPS load margin

Using the previous:

2.5 kW

security load,

you would not normally select a UPS whose maximum output is exactly:

2.5 kW.

A design might provide suitable capacity margin for:

inrush, growth and operating headroom.

For example, if the selected UPS can continuously provide:

4 kW

then the 2.5 kW system is operating at:

2.5/4=62.5%

of that output rating.

Whether this is suitable depends on the required runtime and manufacturer’s performance data.

44. Battery ageing needs to be considered

UPS battery performance deteriorates over time.

A system designed to provide:

30 minutes

when batteries are new may provide materially less after several years if batteries are not maintained.

UPS therefore belongs in the maintenance programme, not merely the installation specification.

45. Generator-backed sites still need transition design

A generator may take time to:

detect loss of supply, start, stabilise and transfer load.

The security system must remain operating during that transition if continuous operation is required.

UPS provides the bridge.

Without it, security systems may reboot each time the building transfers between:

utility power

and

generator power.

46. Power quality can also matter

Security equipment may be sensitive to:

voltage fluctuations, transients and repeated interruptions.

A well-designed UPS can therefore provide more than runtime.

Depending on UPS type and architecture, it may also help condition power supplied to critical electronic systems.

47. Separate critical and non-critical security loads

Not every security device necessarily requires the same backup priority.

For example:

critical camera infrastructure, security servers, ACS controllers and operator systems

may require stronger resilience than:

non-critical convenience devices.

The project can classify security loads so backup capacity is used intelligently.

48. Access-control lock power needs special consideration

Lock power may represent a significant DC load.

In a fail-safe maglock system, battery backup may be required to keep doors secure during ordinary mains failure, subject to the approved life-safety design.

The required runtime therefore depends on:

lock current, number of locks, controller current and battery capacity.

This should be calculated separately from the IT-style UPS calculation where dedicated DC security power supplies are used.

49. Power-loss behaviour should be documented

Every major system should have a defined behaviour during:

mains loss, UPS operation, battery depletion and restoration.

For example:

Mains fails → UPS carries security rack → generator starts → normal operation continues.

Or:

Mains fails → DC battery maintains access control → after defined period battery depletes → doors transition to designed fail state.

This should not be discovered accidentally during the first real blackout.

50. Define failure domains

A failure domain is the amount of the system affected by a single failure.

Examples:

One 48-port switch fails:

40 cameras lost.

One controller fails:

8 doors affected.

One fibre fails:

one floor disappears.

One NVR fails:

64 cameras stop recording.

One UPS fails:

entire security rack shuts down.

The goal is not necessarily to make every failure domain tiny.

The goal is to understand and deliberately accept it.

51. Example failure-domain comparison

Design A

96 cameras → one core switch → one NVR.

Potential major single-point impact:

all 96 cameras

Design B

48 cameras → Switch A → Recorder A
48 cameras → Switch B → Recorder B

Potential major component failure:

approximately half the system

This is not automatically “better” because it costs more.

It simply changes the consequence of a failure.

That consequence should be compared with the risk requirement.

52. Redundancy can exist at several levels

Security resilience can be introduced through:

A project does not necessarily need every layer.

The important point is that resilience can be engineered at more than one place.

53. Overlapping camera views can be a form of resilience

Not all redundancy is technical infrastructure redundancy.

If two cameras independently cover an important entrance, loss of one may still leave useful surveillance.

That can sometimes be more cost-effective than creating full network redundancy for a low-risk location.

The correct resilience strategy depends on:

what function needs to survive.

54. Edge recording protects against some failures, not all

Camera SD recording can help during:

network interruption.

But it does not necessarily protect against:

camera failure

or

loss of power to the camera.

So edge recording should be understood as one resilience layer, not a universal backup solution.

55. Remote monitoring creates WAN dependency

If a site is monitored from a remote GSOC, then the security operation depends on:

the local network, firewall/router, ISP connection, WAN/cloud infrastructure and remote monitoring centre.

A remote-monitoring architecture therefore needs to consider:

What happens when the Internet connection fails?

Possible strategies may include:

local alarm capability, secondary WAN, mobile connectivity or delayed event synchronisation.

The correct response depends on the service model.

56. Dual Internet links are not automatically independent

Two Internet services may appear redundant but still use:

the same building riser, exchange, provider backbone or local termination equipment.

True resilience requires understanding whether the alternate path is genuinely independent enough for the required risk.

57. Remote security services should define degraded mode

Suppose a remotely monitored site loses WAN connectivity.

Questions include:

Are cameras still recording locally?

Does access control continue locally?

Do intrusion alarms still sound locally?

Can site personnel respond?

Does the system automatically reconnect?

Are queued events uploaded later?

This is degraded-mode design.

Managed security depends heavily on understanding degraded modes.

58. Monitoring infrastructure health is part of security operations

Security systems should ideally provide visibility into faults such as:

camera offline, recorder fault, switch failure, disk fault, controller offline, battery fault, communication failure and storage degradation.

If the system fails silently, the organisation may discover the problem only after an incident.

59. SNMP and infrastructure monitoring can help

Network switches, UPS units, servers and other devices may support infrastructure monitoring mechanisms such as SNMP.

This can allow central monitoring systems to identify:

device health, port state, power consumption, UPS status and hardware faults.

The exact architecture depends on client IT policy and product capability.

The broader point is:

Security infrastructure itself should be monitored.

60. Spare capacity should be planned across the architecture

Providing 20% spare switch ports is useful.

But if the server is already at 98% CPU capacity, the system may still be unable to expand.

Future growth should therefore be considered across:

network ports, PoE budget, bandwidth, storage, server resources, rack space, power and licensing.

Spare capacity should be system-wide, not just visible in one device.

61. Capacity planning should consider likely upgrades

Future cameras may use:

higher resolution, more analytics and higher bitrate.

Future access-control devices may require:

more network connections or additional integrations.

Designing only for today’s device count can create an expensive infrastructure replacement later.

62. Security racks need environmental design

Servers, switches, NVRs and storage produce heat.

A security equipment room needs suitable:

cooling, ventilation, power distribution, rack capacity and environmental protection.

Overheating can reduce reliability and equipment life.

The security designer should therefore coordinate with M&E rather than simply specifying:

“19-inch rack by others.”

63. Rack space should be planned in rack units, not guesswork

List every rack-mounted component.

Then include space for:

patch panels, switches, servers, NVRs, fibre termination, cable management, UPS/PDU equipment where applicable and future expansion.

A rack filled to 100% on day one creates poor maintenance conditions.

64. Cable management affects maintainability

Poorly managed patching can turn troubleshooting into a major operational problem.

Infrastructure should be labelled consistently.

For example:

L19-CAM-SW01-P17 → CAM-L19-017

This allows a technician to trace:

camera → port → switch → rack.

Physical documentation should match software naming.

65. Cybersecurity and physical security converge in the rack

Security equipment rooms may contain:

NVRs, ACS servers, network switches and databases containing sensitive access information.

The room therefore needs:

physical access control

as well as

cybersecurity.

A firewall cannot prevent someone from physically disconnecting the server.

A strong door cannot prevent an exposed Internet service from being attacked remotely.

Both forms of security are necessary.

66. A practical architecture example

Assume a two-floor office with:

80 CCTV cameras

24 access-controlled doors

2 operator workstations

and a central security room.

A reasonable conceptual architecture might be:

LEVEL 19

40 CAMERAS

    |

2 x PoE ACCESS SWITCHES

    |

    +—— Fibre A ——

                         |

LEVEL 18                 |

40 CAMERAS               |

    |                    |

2 x PoE ACCESS SWITCHES  |

    |                    |

    +—— Fibre B —–+—- SECURITY CORE

                              |

                              +—- VMS / NVR

                              |

                              +—- STORAGE

                              |

                              +—- CCTV WORKSTATION

ACCESS CONTROL

24 DOORS

    |

DOOR CONTROLLERS

    |

SECURITY / ACS NETWORK

    |

ACS SERVER / DATABASE

    |

ACS WORKSTATION

The drawing is conceptual rather than a prescribed architecture.

The important thing is that each dependency can now be analysed.

67. Calculate the CCTV load

Assume average camera bitrate:

3 Mbps

For 80 cameras:

80×3Mbps=240Mbps

If each floor carries approximately 40 cameras:

40×3Mbps=120Mbps

per floor before additional traffic.

So 1 Gbps floor uplinks would provide substantial bandwidth headroom for this simplified example.

But we still need to consider:

peak bitrate, viewing, analytics and future cameras.

68. Calculate PoE

Assume average design PoE consumption:

12 W per camera

For 40 cameras:

40×12=480W

If each floor uses two PoE switches, the cameras could be divided approximately:

20 cameras per switch.

Each switch would carry roughly:

20×12=240W

camera load.

A switch with suitable port count and PoE capacity could therefore support that design with margin.

Again, this is a simplified worked example.

Actual camera maximum consumption must be used.

69. Consider the switch failure

With two access switches per floor:

one switch failure might remove approximately:

20 cameras

rather than all 40.

That may be an acceptable failure domain.

For a higher-risk area, cameras could potentially be distributed so that critical locations do not all depend on the same switch.

70. Consider the core failure

If both floors ultimately depend on one core switch, the system still has:

one major central failure point.

The project can then decide whether:

a redundant core

is justified.

That is a risk/cost decision.

The architecture diagram makes the decision visible.

71. Consider power

If each floor’s camera switches rely on:

normal building power only,

then the cameras disappear during a blackout even if the central NVR has UPS.

Therefore the design must determine which:

switches and associated transmission devices

also require backup.

72. Consider remote monitoring

If PATH or another provider monitors the system remotely, the site would additionally require:

SECURITY NETWORK

      |

 FIREWALL / SECURE GATEWAY

      |

  WAN / INTERNET

      |

     GSOC

Now the WAN becomes part of the security service.

The design should define:

normal mode

and

WAN-loss mode.

73. Commission the infrastructure, not just the devices

A CCTV camera can pass an image test while the network architecture remains poorly commissioned.

Infrastructure testing should include:

bandwidth validation, PoE loading, device addressing, time synchronisation, firewall connectivity, server services, failover where applicable, UPS operation, power-loss behaviour, network-loss behaviour and health monitoring.

This is where engineering assumptions become proven system behaviour.

74. Test realistic failures

The project should not deliberately create unsafe conditions, but authorised commissioning can simulate appropriate failures.

Examples include:

disconnect an access-switch uplink and confirm expected cameras are lost;

remove one network path in a redundant design and confirm traffic fails over;

disconnect WAN and verify local recording continues;

simulate NVR failure where failover is provided;

remove mains power and confirm UPS behaviour;

check that appropriate faults appear to the operator.

A redundancy feature that has never been tested should not automatically be assumed to work.

75. Keep the as-built infrastructure documentation

At handover, the project should have enough information for future support personnel to understand the architecture.

A useful documentation set can include:

network topology, VLAN schedule, IP schedule, switch schedule, port mapping, server specifications, VM allocation, firewall requirements, rack layouts, fibre routes, UPS loading, power diagrams and backup/recovery information.

This is not paperwork for its own sake.

It allows the managed-security team to support the system years later.

Common Infrastructure Engineering Mistakes

Practical Security Infrastructure Design Checklist

A project should be able to answer the following before infrastructure is approved:

1. What are all the security-system components?
2. What network does each component use?
3. Which systems are physically separated and which are only VLAN-separated?
4. What IP-addressing structure is used?
5. How many usable switch ports are required?
6. What spare port capacity remains?
7. What is the PoE load per switch?
8. What is the switch’s actual PoE budget?
9. What is the expected camera bandwidth?
10. What is the expected peak load?
11. What traffic flows to recording, analytics and operator workstations?
12. Are uplinks sized with meaningful headroom?
13. Where is fibre required?
14. What happens if one fibre fails?
15. What happens if one access switch fails?
16. What happens if the core switch fails?
17. What happens if the security server fails?
18. What happens if the database fails?
19. What functions continue locally?
20. Are systems physical or virtual?
21. If virtual, what host/storage/network dependencies exist?
22. Where does recording storage reside?
23. Is system time synchronised?
24. Are DNS and other infrastructure dependencies documented?
25. Are firewall rules defined precisely?
26. Is remote access secured?
27. Are default credentials removed?
28. Are user privileges appropriate?
29. What is the total power load?
30. Which devices need UPS or battery backup?
31. Does the entire operating chain survive power loss?
32. What UPS runtime is required?
33. What happens after the batteries deplete?
34. Is generator transfer accounted for?
35. What are the major failure domains?
36. Where is redundancy actually required?
37. Are supposedly redundant systems genuinely independent?
38. Is the WAN part of the managed-security dependency?
39. What happens if WAN connectivity is lost?
40. Are infrastructure faults monitored?
41. Is there sufficient future network, server, storage, power and rack capacity?
42. Are racks environmentally suitable?
43. Is physical access to security infrastructure controlled?
44. Has failure behaviour been tested?
45. Is the complete infrastructure documented at handover?

Conclusion

Modern physical security depends on far more than cameras, readers and alarms.

Underneath those devices sits an infrastructure chain:

power → network → controller → server → database → storage → workstation → monitoring operation

The system is only as reliable as the dependencies supporting it.

Good infrastructure engineering therefore asks more than:

“Does the camera have an IP address?”

It asks:

Can the network carry the load?

Can the switch power the devices?

What happens if an uplink fails?

Does the security function survive server loss?

Does the entire system remain operational during a power outage?

Can the operator see when the infrastructure itself has failed?

The most useful design principle is:

Engineer for failure as carefully as you engineer for normal operation.

Normal operation tells us whether the system works today.

Failure-state engineering tells us whether the security system can still protect the premises when something goes wrong.

For a managed security provider such as PATH, that distinction is particularly important.

The objective is not only to supply and install security equipment.

It is to understand and manage the full environment that allows the security service to remain:

available, secure, resilient and supportable throughout its lifecycle.