Access Control and Intrusion System Design: Doors, Locks, Sensors, Alarm Logic and Life-Safety Interfaces

An access-controlled door is not simply:

reader + lock

It is a small security system.

A properly designed door may involve:

credential reader → access controller → locking device → door position monitoring → request-to-exit → emergency release → fire interface → alarm logic → CCTV verification → operator response.

Each component has a different purpose.

If one of those functions is poorly designed, the door may still appear to “work” while the security outcome is wrong.

For example:

• the reader grants access but the lock never releases;
• the lock releases correctly but the system cannot tell whether the door actually opened;
• the door contact shows an alarm every time somebody exits legitimately;
• a fire interface unlocks more doors than intended;
• an emergency release device is wired but not monitored;
• an intrusion sensor generates constant false alarms;
• a controller loses communication and nobody knows what the door will do.

This guide focuses on how access control and intrusion systems are engineered as complete systems, rather than repeating basic definitions already covered elsewhere in PATH Insights.

The important design principle is:

Every secured opening and every intrusion zone should have a defined normal state, authorised state, alarm state and failure state.

1. Start with the security function of the door

Before choosing the reader or lock, define what the door is supposed to achieve.

For example:

Staff may enter using an authorised credential between 07:00 and 20:00.

Visitors may enter only when remotely released by reception.

Unauthorised opening must generate an alarm.

The door must remain available for emergency egress in accordance with applicable life-safety requirements.

That tells the designer far more than:

“Card reader required.”

A proper door schedule should therefore identify:

• door purpose;
• entry direction;
• exit direction;
• credential requirement;
• normal lock state;
• after-hours behaviour;
• life-safety requirements;
• monitoring;
• alarm behaviour;
• CCTV association;
• intercom requirement;
• power/failure behaviour.

2. Think of an access-controlled door as a control loop

A useful simplified architecture is:

USER

  |

  v

READER

  |

  v

ACCESS CONTROLLER

  |

  +——> LOCK

  |

  +——> DOOR POSITION CONTACT

  |

  +——> REQUEST TO EXIT

  |

  +——> EMERGENCY RELEASE / LIFE-SAFETY INTERFACE

  |

  +——> SECURITY EVENTS / ALARMS

The reader answers:

Who is requesting entry?

The controller answers:

Are they authorised?

The locking device answers:

Should the door physically release?

The door contact answers:

Did the door actually open or close?

The alarm logic answers:

Did anything happen that should concern security?

Those are separate functions.

3. Reader does not equal controller

A reader usually does not make the final access decision by itself.

It reads a credential and passes credential information to the access-control system.

The controller then evaluates factors such as:

• credential validity;
• access group;
• time schedule;
• door permissions;
• system state;
• anti-passback rules where used; and
• other programmed conditions.

If access is authorised, the controller sends the appropriate command to the locking circuit.

This distinction matters during troubleshooting.

If someone presents a valid card but the door remains locked, the fault could be:

reader → controller communication

credential programming

controller output

lock power

lock wiring

or

the mechanical door itself.

Simply replacing the reader may achieve nothing.

4. Credential technology is only one part of the system

Projects often spend considerable effort choosing between:

card technologies, mobile credentials, NFC, BLE or biometrics.

Those choices matter.

But credential technology does not compensate for a poor door design.

A high-security credential used on a door with:

no door monitoring, weak locking, exposed cabling or poor alarm handling

still creates a weak overall security point.

The correct design considers the entire path:

credential → reader → controller → communications → lock → door/frame → monitoring → response

5. Understand fail-safe and fail-secure locking

These terms are often misunderstood.

Fail-safe

A fail-safe locking arrangement releases when power is removed.

The simplified behaviour is:

Power present = locked
Power removed = unlocked

Electromagnetic locks commonly operate this way.

Fail-secure

A fail-secure arrangement remains mechanically secure when power is lost.

In simplified terms:

Power loss = remains locked from the secure side

The actual egress behaviour depends on the complete hardware arrangement.

Electric strikes and certain electric locks may be configured this way.

Important distinction

Fail-safe / fail-secure describes lock behaviour under loss of power.

It does not by itself determine whether the complete door satisfies:

fire, emergency-egress or building-code requirements.

Those requirements need to be coordinated with the architect, door hardware specialist, fire consultant/QP and the applicable authority requirements.

6. Do not choose fail-safe or fail-secure simply from a security preference

From a purely security perspective, one might say:

“Keep everything locked during power failure.”

But life safety may require a different behaviour.

Equally:

“Everything unlocks during power failure”

may create unnecessary security exposure.

The correct design considers:

security requirement

emergency egress

fire strategy

door hardware

power architecture

and

operational response.

Different doors within the same building may therefore behave differently.

7. Electromagnetic lock versus electric strike

These are two common electronic locking approaches, but they work differently.

Electromagnetic lock

A maglock creates holding force between:

an electromagnet

and

an armature plate.

Advantages can include:

• simple electrical operation;
• strong holding force;
• relatively straightforward installation in suitable applications.

Design considerations include:

• it normally requires continuous power to remain locked;
• door alignment matters;
• emergency release arrangements are important;
• power supply capacity must be considered;
• the entire egress/release path must be coordinated carefully.

Electric strike

An electric strike replaces or modifies the door-frame strike so the latch can be released electronically.

Potential advantages include:

• compatibility with mechanical locking arrangements;
• some models can retain secure behaviour during power loss;
• the door may continue using conventional mechanical egress hardware.

But suitability depends heavily on:

door construction, lockset, fire rating, frame construction and required security performance.

8. Lock selection must include the physical door

Electronic access control cannot be designed separately from:

door leaf

frame

hinges

locking hardware

door closer

panic hardware

and

door alignment.

A powerful electronic lock installed on a weak frame does not create a strong security door.

Similarly, a perfectly specified access-control system cannot compensate for:

a door that does not close reliably.

Consultant’s perspective

Many apparent “access-control faults” are actually mechanical door faults.

If the closer does not pull the door fully into the frame:

the lock may not engage

and

the door contact may remain open.

The software then reports the symptom.

The root cause is mechanical.

9. Door contacts are critical

The door position contact tells the system whether the door is:

open

or

closed.

Without it, the access-control system may know that it issued an unlock command, but it cannot properly determine what happened afterwards.

A typical monitored sequence is:

Valid credential → unlock → door opens → door closes → lock restores

The door contact provides the physical-state feedback.

10. What is Door Forced Open?

A Door Forced Open event generally occurs when the system detects the door opening without a valid authorised event that explains the opening.

For example:

Door is locked
No valid credential
No authorised REX
Door contact changes to open

The system may interpret this as:

unauthorised opening

and raise an alarm.

The exact logic depends on the platform configuration.

11. What is Door Held Open?

A Door Held Open event is different.

The system may have legitimately unlocked the door.

The person passes through.

But the door remains open beyond the allowed period.

For example:

Valid credential
Door unlocks
Door opens
Expected close period expires
Door is still open

That may generate:

Door Held Open

This is why the access system needs to understand the sequence of events, not merely whether the contact is open.

12. Door Forced and Door Held are different security problems

Door Forced suggests:

The door opened without a valid reason.

Door Held suggests:

The opening may have been legitimate, but the secured boundary has not been restored.

The operator response may therefore be different.

For example:

Door Forced at Critical Room
High-priority security alarm.

Door Held at Staff Pantry
Lower-priority operational alarm after a defined delay.

This type of prioritisation becomes important later when designing the full cause-and-effect matrix.

13. Request-to-exit is not simply “the exit button”

Request-to-exit, or REX, tells the access-control system that someone is legitimately leaving.

It may be generated by:

• push button;
• motion sensor;
• door hardware;
• access credential;
• another authorised input.

Depending on the system architecture, REX may:

request the controller to unlock the door

and/or

suppress a Door Forced alarm during legitimate egress.

These are not necessarily the same function.

14. Why REX logic matters

Imagine a door with free egress.

A person pushes the door open from the secure side.

If the access-control system has no legitimate egress indication, it sees:

door locked → contact opens

and may generate:

Door Forced

even though the person was leaving normally.

That is a logic/configuration problem.

The system needs to distinguish:

authorised exit

from

unauthorised opening.

15. Emergency door release needs to be designed deliberately

Certain electronically locked doors may require an emergency release arrangement.

The exact requirement depends on:

door function, egress arrangement, fire strategy, applicable regulations and approval by the relevant project professionals.

Where an emergency release device forms part of the design, the engineer should determine:

• what circuit it interrupts;
• whether release is direct or controller-dependent;
• whether activation is monitored;
• what alarm/event is generated;
• what happens when the device is reset;
• whether security receives notification.

A device should not simply be drawn on a schematic because:

“we always put one beside the reader.”

Its electrical and operational purpose needs to be understood.

16. Direct lock interruption versus software command

This is an important engineering distinction.

An emergency-release circuit can sometimes be designed to act directly on the locking power circuit, rather than relying solely on software to send an unlock command.

Conceptually:

LOCK POWER

   |

   +—- Emergency Release

   |

   +—- Other Required Safety Interface

   |

   +—- Lock

The actual arrangement depends on the door hardware and approved life-safety design.

The broader principle is:

A safety-critical release function should not accidentally become dependent on a software event that may not occur during a failure.

The project team should coordinate the correct arrangement with the relevant qualified parties.

17. Fire alarm integration should be defined door by door

One of the worst approaches is:

Fire alarm = unlock every access-controlled door.

That may or may not correspond to the approved fire strategy.

Instead, each door should have a defined fire-state behaviour.

For example:

The exact required behaviour must come from the project’s approved fire/life-safety design.

Security should implement that requirement, not invent it.

18. Fire interface and access control need a testable sequence

The final design should allow commissioning personnel to test:

Fire signal received

↓

designated door changes state correctly

↓

event appears on access-control system where required

↓

security operator understands why the door changed state

↓

system returns correctly after reset

This is more useful than simply drawing:

“Interface to FAP”

on a schematic.

19. Controller architecture matters

An access-control system normally has several layers.

For example:

ACCESS CONTROL SERVER

        |

     NETWORK

        |

  MAIN CONTROLLER

        |

   DOWNSTREAM BUS

        |

 DOOR MODULES

        |

 READERS / LOCKS / INPUTS

The specific terminology varies between manufacturers.

The important engineering questions are:

• how many doors depend on each controller;
• what happens if the network fails;
• what happens if the server fails;
• what happens if the controller fails;
• where access decisions are stored;
• how much spare capacity exists;
• whether critical doors should be distributed across failure domains.

20. What should happen when the access-control server fails?

A good access-control architecture should not necessarily require every door to stop functioning just because the central management server is unavailable.

Depending on the platform:

controllers may retain credential databases, schedules and programmed logic locally.

The system may therefore continue making access decisions while central monitoring is temporarily unavailable.

The exact behaviour is platform-specific and must be verified.

The engineering question is:

What functionality remains locally when the server or network is unavailable?

21. What should happen when the controller fails?

This is more serious because the controller may directly operate multiple doors.

The impact depends on:

• lock type;
• power architecture;
• downstream modules;
• local hardware behaviour.

The designer should therefore know:

How many doors are lost if one controller fails?

This is another example of a failure domain.

22. Do not put every critical door on one controller without considering failure

Suppose one controller serves:

eight critical rooms.

If the controller fails, all eight may become affected simultaneously.

Another architecture might distribute them across multiple controllers.

The correct choice depends on:

risk, cost, available redundancy and operational requirements.

The principle is the same as network engineering:

Understand how much security capability a single failure can remove.

23. Reader communications matter

Modern systems may use technologies such as:

OSDP

or manufacturer-specific communications.

The technical details will depend on the selected platform.

From an engineering perspective, important questions include:

• reader supervision;
• encryption where supported;
• cable distance;
• topology;
• grounding;
• addressing;
• power requirements;
• tamper monitoring.

A reader that merely sends an unsupervised signal without visibility into wiring faults may provide less system integrity than a properly supervised communications architecture.

24. Lock power must be calculated

Electronic locks consume power.

So do:

readers, controllers, expansion modules and interfaces.

A door power design should determine:

normal load

maximum simultaneous load

battery/UPS requirement

voltage drop

cable size

and

future expansion.

For example, if eight maglocks each consume:

500 mA at 24 VDC

then:

8×0.5A=4A

The power supply needs to support:

the locks

plus

other connected equipment

plus

appropriate design margin.

25. Voltage drop can cause strange intermittent faults

A lock specified for 24 VDC may not operate properly if cable resistance means the device receives significantly less voltage at the end of a long run.

The simplified DC voltage-drop relationship is:

Vdrop=I×R

As:

current increases

or

cable resistance increases,

voltage drop increases.

This is particularly important for:

long cable runs and high-current locking devices.

A design that works on the bench may become unreliable once installed hundreds of metres away.

26. Access control should monitor more than the credential

Depending on the project’s risk, useful supervised points may include:

• door position;
• emergency release state;
• controller tamper;
• power supply fault;
• battery fault;
• enclosure tamper;
• network/device offline;
• reader communication loss.

This gives the security team visibility into the health of the access-control system, not merely user access events.

27. Intrusion detection starts with the threat scenario

Intrusion Detection Systems, or IDS, should not begin with:

“How many PIRs should we install?”

Start with:

What unauthorised action are we trying to detect?

For example:

Opening a protected door

Entering a room

Crossing a perimeter

Breaking a window

Approaching a Critical Asset

Opening an equipment enclosure

The sensor should match the event.

28. Different sensors solve different problems

A building IDS can use several types of detection.

Door contact

Detects:

door open / closed

Useful for boundary openings.

PIR

Passive Infrared sensors detect changes in infrared energy associated with movement.

Useful for:

internal motion detection.

Performance depends on:

mounting, environment, temperature and scene.

Dual-technology sensor

Combines two detection technologies, commonly to reduce false alarms.

The exact logic depends on the device.

Glass-break sensor

Designed to detect characteristics associated with glass breaking.

Useful where glazing forms part of the intrusion boundary.

Beam detector

Creates a defined detection path.

Useful across:

open areas or perimeter approaches.

Vibration / shock detector

Can detect attack against:

doors, walls, glass or other protected surfaces

depending on the product.

Tamper input

Detects attempts to:

open, remove or interfere with the security device or enclosure.

29. Do not use one sensor type everywhere

A PIR may be useful for detecting someone inside a room.

It does not tell you:

which door they used.

A door contact tells you:

the door opened.

It does not necessarily tell you:

whether someone subsequently remained inside the room.

These devices can therefore complement one another.

For a higher-risk area:

perimeter detection + door monitoring + internal detection

may provide more useful information than one sensor alone.

30. Build intrusion detection in layers

Consider a secure equipment room.

Possible layers might include:

Boundary

Door contact detects opening.

Access Control

Credential system determines whether opening was authorised.

Interior

Motion detection identifies movement inside the room.

Asset

Cabinet tamper monitors access to particularly sensitive equipment.

CCTV

Camera provides visual verification.

Each layer answers a different question.

31. What is an alarm zone?

An intrusion zone is a logical grouping or monitored input representing a protected condition.

Examples:

Server Room Door

Roof Access

Loading Bay Beam

Critical Equipment Cabinet

The naming should make the alarm immediately understandable.

Avoid names such as:

Zone 37

unless there is a very clear operational mapping.

32. 24-hour versus armed intrusion zones

Not every sensor needs to behave the same way all day.

Some zones may be active continuously.

Others may be active only when:

the site

or

the area

is armed.

For example:

A cabinet tamper may require:

24-hour monitoring.

An office-area motion sensor may be relevant primarily:

after hours.

The exact zoning strategy depends on the operational model.

33. Avoid creating an alarm system nobody trusts

A sensor generating constant nuisance alarms quickly loses operational value.

Operators may begin:

ignoring the alarm

or

automatically clearing it.

That is dangerous.

False or nuisance alarms can come from:

poor sensor selection, bad positioning, unstable doors, air movement, environmental conditions, poor thresholds or unsuitable analytics.

Design principle

Alarm quality matters more than alarm quantity.

The aim is not to produce the maximum number of events.

The aim is to produce meaningful events that operators will act upon.

34. Alarm verification should be designed where useful

An intrusion event becomes much more useful when security can quickly see what caused it.

For example:

Roof access alarm

↓

associated CCTV automatically displayed

↓

operator sees maintenance contractor

or

operator sees unauthorised person

The first may be operationally resolved.

The second may require immediate response.

We will cover the wider integration and cause-and-effect architecture in the later PATH integrated-security guide.

35. Access control and IDS should not generate duplicate meaningless alarms

Suppose a door is monitored by both:

access control

and

intrusion detection.

If someone enters with an authorised credential, the system should not unnecessarily produce:

Valid Access

plus

Intrusion Alarm

plus

Door Forced

for one legitimate event.

The systems need coherent logic.

Otherwise the operator receives three alarms for something that should be normal.

36. Build the door state machine

One useful way to engineer complex access-controlled doors is to define their possible states.

For example:

State 1 — Secure

Door closed.
Lock secure.
No alarm.

State 2 — Valid access

Credential authorised.
Lock releases for defined period.

State 3 — Door open

Door opens during authorised period.

State 4 — Door restored

Door closes.
Lock secures.

Exception A — Door forced

Door opens without authorised sequence.

Exception B — Door held

Door remains open beyond allowable period.

Exception C — Emergency release

Emergency release device changes lock state.

Exception D — Fire condition

Door follows approved fire logic.

Exception E — Power or controller failure

Door follows designed fail state.

Once those states are understood, programming becomes much clearer.

37. Example door event logic

A simplified example might look like this:

This is only an illustrative engineering example, not a universal door configuration.

Each project needs its own approved logic.

38. Do not forget door timing

Access-control systems often include several timing values:

unlock duration

door-open grace period

door-held alarm delay

REX timing

alarm reset timing

Poor settings can make a perfectly installed door annoying or insecure.

For example:

Unlock time too short:

user presents card but cannot open the door before it relocks.

Unlock time too long:

door remains unsecured unnecessarily.

Door-held timer too short:

normal users constantly generate alarms.

Door-held timer too long:

security does not learn about an open door quickly enough.

Timing should match actual door operation.

39. Different users may require different access behaviour

A security design may distinguish between:

staff, cleaners, contractors, visitors and administrators.

Access control can implement:

who

where

and

when.

But permissions should follow operational requirements rather than creating hundreds of unnecessary access groups.

Overly complex access structures become difficult to maintain and audit.

A simpler role-based structure is usually easier to control.

40. Access control should follow least privilege

The principle is:

Give users access only to the areas and periods necessary for their role.

For example:

General staff:

office areas.

IT personnel:

office + server rooms.

Facilities personnel:

office + selected plant areas.

Security management:

appropriate wider access.

This becomes particularly important for:

Critical Assets and sensitive areas.

41. Door hardware needs to match the security level

A reader and lock do not automatically create a high-security door.

The surrounding construction matters.

Consider:

• door leaf strength;
• frame anchoring;
• glazing;
• hinges;
• lock mounting;
• exposed fixings;
• adjacent panels;
• ceiling bypass;
• cable access.

A sophisticated access-control system on a physically weak enclosure creates an imbalance.

The security level of the opening is effectively limited by its weakest component.

42. Double-leaf doors require extra coordination

Double-leaf doors can create additional complexity.

Questions may include:

• which leaf is active;
• where the lock engages;
• whether both leaves are monitored;
• how emergency egress operates;
• whether automatic flush bolts are involved;
• how sequencing works;
• where the reader and release devices are positioned.

These doors should be coordinated with the architectural door-hardware schedule early.

Trying to “add access control later” can create difficult compromises.

43. Automatic doors need security coordination

Automatic sliding or swing doors may involve:

door operator controls, access control, safety sensors, fire signals and emergency release.

The access-control system may only provide one part of the command chain.

The security designer needs to know:

Who actually controls the door motor?

What signal does access control provide?

What happens during fire?

What happens during power failure?

How is door position monitored?

The interface needs to be documented clearly.

44. Turnstiles are not simply doors without hinges

Turnstiles introduce issues such as:

• entry/exit direction;
• credential sequence;
• tailgating;
• emergency release;
• fire state;
• barrier position;
• lane controller;
• visitor management;
• accessible lane requirements;
• occupancy counting where applicable.

The same access-control principles apply, but the mechanical and operational behaviour differs substantially from a conventional door.

45. Tailgating is not solved by access control alone

A card reader proves:

a credential was accepted.

It does not always prove:

only one authorised person passed through.

Where tailgating risk is significant, additional measures may include:

• turnstiles;
• speed gates;
• mantrap-style arrangements where appropriate;
• guards;
• sensors;
• analytics;
• operational supervision.

The solution should be proportionate to the risk.

46. Cabling architecture should be part of the design

Access-control cabling may include:

• reader data;
• reader power;
• lock power;
• door contact;
• REX;
• emergency release monitoring;
• fire interface;
• intercom integration;
• downstream controller communications.

These cables may have different:

current, shielding and distance requirements.

A generic note such as:

“Provide security cable”

is not sufficient for a proper detailed design.

47. Supervising a circuit improves fault visibility

Where supported, supervised inputs can help distinguish between:

normal state

alarm state

and

certain wiring faults or tampering conditions.

The exact method depends on the access-control or intrusion platform.

The engineering objective is:

detect not only the security event, but also certain attempts to defeat or disconnect the monitoring circuit.

48. Panel locations matter

Controllers and power supplies should not be positioned simply wherever spare wall space exists.

Consider:

• physical security;
• environmental conditions;
• maintenance access;
• cable distances;
• network connection;
• emergency power;
• fire zoning;
• failure impact.

Placing the controller for a Critical Area on the public side of the same door it controls may introduce unnecessary risk.

49. Design for maintenance

A system that cannot be serviced safely and efficiently will deteriorate.

The design should allow technicians to:

identify cables, access panels, replace batteries, test locks, replace readers and diagnose faults

without unnecessary disruption.

Good documentation is part of engineering.

Panel drawings and labels should correspond to:

door IDs

and

software names.

50. Commission the whole door, not individual devices

A reader test that says:

Card reads successfully

does not prove the door system is commissioned.

The test should follow the complete sequence.

Example valid-access test

1. Door closed and secure.
2. Present authorised credential.
3. Reader indicates access granted.
4. Lock releases.
5. Door opens.
6. Door contact changes state.
7. No false Door Forced alarm.
8. Door closes.
9. Contact restores.
10. Lock secures.
11. Event appears correctly in software.

That proves an operational sequence.

51. Test invalid access

Present an unauthorised credential.

Verify:

• door remains secure;
• event is recorded;
• alarm behaviour matches design;
• no unintended release occurs.

52. Test Door Forced

With the door secure:

open it without a valid access sequence using the agreed test method.

Verify:

• correct Door Forced event;
• correct priority;
• CCTV association if configured;
• operator notification;
• response workflow.

53. Test Door Held

Grant valid access.

Hold the door open beyond the configured delay.

Verify:

Door Held event occurs at the expected time.

Then close the door.

Verify:

alarm restores correctly.

54. Test emergency release

Where provided and where testing can be undertaken safely with the authorised project team:

activate the release.

Verify:

• lock behaviour;
• access-control event;
• operator indication;
• physical release;
• reset process.

Any life-safety testing should be coordinated with the appropriate responsible parties.

55. Test the fire interface

The project should verify that each applicable door follows its approved fire-state behaviour.

Do not accept only:

“Fire cable connected.”

Test the actual outcome.

56. Test failures

Engineering commissioning should include relevant failure scenarios.

Examples:

Network disconnected

What continues locally?

Server unavailable

Can doors still process authorised credentials?

Controller offline

What happens to affected doors?

Lock power failure

What state does the door enter?

Reader disconnected

Is the fault visible?

Door contact disconnected

Does the system identify abnormal condition where supervision exists?

These tests reveal weaknesses that normal-operation testing does not.

57. Intrusion sensors also need scenario testing

A PIR should not simply be tested by waving a hand in front of it.

Test:

• intended detection area;
• dead zones;
• normal environmental conditions;
• alarm reset;
• tamper;
• CCTV verification where used;
• alarm reporting;
• night/armed mode.

For a beam:

test the intended crossing path.

For a door contact:

test actual door operation.

Commission against the threat scenario.

58. Document the final configuration

A proper handover should allow another engineer to understand the system later.

Useful information includes:

• door schedule;
• reader types;
• controller assignments;
• input/output assignments;
• lock types;
• power-supply locations;
• emergency-release logic;
• fire interface;
• alarm delays;
• door forced/held settings;
• intrusion zones;
• network addresses where relevant;
• software naming conventions;
• as-built drawings;
• test records.

Without this, future troubleshooting becomes archaeology.

A Practical Door Design Checklist

Before approving an access-controlled door, ask:

1. What is the door’s security purpose?
2. Who may enter?
3. During what schedule?
4. What credential is used?
5. Is exit controlled or free?
6. What lock type is appropriate?
7. Is the lock fail-safe or fail-secure?
8. What is the designed power-loss behaviour?
9. Does the mechanical door suit the electronic lock?
10. Is the frame strong enough?
11. Is door position monitored?
12. Is REX required?
13. How does legitimate exit avoid a Door Forced alarm?
14. Is an emergency release required by the approved design?
15. Is activation monitored?
16. What is the fire-state behaviour?
17. Has this been coordinated with the relevant fire/life-safety professionals?
18. What happens if the server fails?
19. What happens if the controller fails?
20. What happens if lock power fails?
21. Is the controller enclosure monitored?
22. Is power-supply health monitored?
23. Is battery condition monitored where applicable?
24. Is associated CCTV required?
25. What constitutes Door Forced?
26. What constitutes Door Held?
27. What are the alarm delays?
28. What is the alarm priority?
29. What should the operator do?
30. Has every important state been tested?

A Practical Intrusion Design Checklist

For each intrusion zone:

1. What intrusion event are we trying to detect?
2. What sensor technology matches that event?
3. Is the zone active 24 hours or only when armed?
4. Can normal activity create nuisance alarms?
5. Is the sensor positioned correctly?
6. Is the circuit supervised where required?
7. Is device tamper monitored?
8. What happens if communication fails?
9. What is the alarm priority?
10. Is visual verification available?
11. What does the operator do after the alarm?
12. Does the zone restore automatically or require acknowledgement?
13. Has the real detection area been tested?
14. Has false-alarm behaviour been assessed?
15. Is the zone name immediately understandable?

Common Engineering Mistakes

Treating the reader as the whole access-control system.
The reader is only one part of the control chain.

Choosing locks without reviewing the actual door and frame.
Mechanical and electronic security need to work together.

Using fail-safe and fail-secure as substitutes for life-safety design.
Those terms describe lock behaviour, not the complete compliance strategy.

Drawing break glass and fire interfaces without defining their electrical logic.

Using one universal fire-unlock behaviour for every door without confirming the approved strategy.

Installing door contacts but programming the wrong alarm sequence.

Generating Door Forced alarms during normal egress.

Using extremely short Door Held timers that generate constant nuisance alarms.

Putting too many critical doors behind one controller without considering failure impact.

Powering locks without checking current demand and voltage drop.

Installing PIRs wherever there is empty wall space instead of designing to a threat scenario.

Generating so many alarms that operators stop trusting the system.

Commissioning devices individually instead of testing the complete operational sequence.

A Practical Engineering Workflow

The overall process can be summarised as:

Security requirement

↓

Door / protected-area function

↓

Authorised and unauthorised scenarios

↓

Physical door and lock selection

↓

Reader and controller architecture

↓

Door monitoring and REX

↓

Life-safety / fire interfaces

↓

Intrusion sensing

↓

Power and communications

↓

Alarm logic

↓

CCTV verification

↓

Failure-state design

↓

Installation

↓

Scenario-based commissioning

↓

Operational handover

Conclusion

Good access control is not achieved by putting a reader beside a door.

And good intrusion detection is not achieved by filling a building with sensors.

Both systems need to be engineered around states and events.

For every secured opening, the designer should know:

What does normal look like?

What does authorised access look like?

What does unauthorised opening look like?

What happens during emergency release?

What happens during fire?

What happens when power, communications or a controller fails?

For every intrusion zone:

What event are we detecting?

How confidently can we detect it?

What could create a false alarm?

What should happen once the alarm occurs?

The objective is not simply to install devices.

It is to create a system where:

access is controlled, abnormal conditions are detected, alarms are meaningful, life-safety interfaces behave correctly and failures occur in predictable ways.

For PATH, that forms the second part of the technical chain:

CCTV shows us what is happening.

Access control determines who should be allowed through.

Intrusion detection tells us when something happens outside the expected access process.