Verification and safety
Software can affect doors, alarms, cameras, gates and emergency workflows. Check the physical outcome, permissions and failure behaviour before making changes to a live system.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
General process only; site safety and regulatory approval remain local responsibilities.
On this page
Overview#
Physical security software can observe people, grant access, suppress or generate alarms, move equipment, and change emergency response. Verification must therefore cover both information behaviour and physical consequence.
Evidence levels#
| Level | Evidence available | What may be claimed |
|---|---|---|
V0 |
Draft notes, secondary material, or unresolved contradictions | Nothing beyond clearly marked work in progress |
V1 |
Applicable primary sources reviewed and scope stated | Source verified description within that scope |
V2 |
V1 plus practical cross check and static consistency review | Reviewed guidance; still no runtime or interoperability claim |
V3 |
Authorised test with exact environment, procedure, expected/actual results, and evidence | Only the behaviour actually observed in that environment |
Source review isn't execution. Execution isn't conformance. A successful test of one firmware build isn't proof for a product family, and conformance to a profile isn't proof that two optional feature sets meet a project's use case.
Verification layers#
Verify independently:
- Syntax: encoding, frame, schema, and message parsing.
- Protocol state: sequencing, correlation, timeout, retry, reconnect, and error handling.
- Semantics: identities, units, state transitions, timestamps, priorities, and authority.
- Security: peer identity, authorisation, certificate/path validation, replay resistance, secrets, and audit.
- Interoperability: exact client/server/device versions and negotiated options.
- Operations: upgrades, restart, clock loss, partial outage, certificate rotation, and recovery.
- Physical outcome: independent observation of intended and unintended effects.
Safety gate for actuation#
Don't perform an actuation test merely because the protocol call is understood. Before any live test, the system owner and validation lead should establish:
- written authorisation and named site/safety owners;
- an exact target and excluded systems;
- a maintenance window and notification plan;
- an isolated test device or proven non actuating mode where possible;
- independent state observation, not only the requesting application's response;
- abort conditions, rollback, manual override, and recovery personnel;
- preservation of egress, fire, emergency communication, and other independent safeguards;
- data handling rules for images, audio, credentials, biometrics, and logs.
NIST's Guide to Operational Technology Security, SP 800-82 Rev. 3 explicitly includes physical access control and building automation within OT and emphasizes performance, reliability, and safety constraints. The knowledge base adopts that conservative framing wherever software can affect the physical environment.
Recording environment validation#
Only upgrade an exact page claim or example to V3 when a reviewer accepts a runtime validation record containing:
- date, operator, authorisation reference, and environment isolation;
- exact hardware, firmware, software, library, configuration, and network path;
- sanitised inputs and expected results;
- actual results, timestamps, logs or trace identifiers, and deviations;
- negative/degraded cases attempted;
- cleanup/recovery confirmation;
- the narrow claim supported by the evidence.
Never store live passwords, tokens, private keys, biometric templates, card secrets, access codes, resident data, or unredacted surveillance evidence in this library.
See the detailed verification policy and environment validation checklist.