Physical Security Dev Notes is an open-source, plain-Markdown knowledge base for developers and integrators working across video surveillance, physical access control, alarm monitoring, intercom, building automation, OT, identity, and their supporting network services. It explains how systems fit together, what each protocol actually guarantees, where legacy risk remains, and how to build integrations that fail safely.
The canonical repository is tegridydev/physical-security-dev. The library is designed to be cloned and used locally without a documentation server or build step.
The library is protocol first, global in scope, and evidence led. It is not a replacement for a standard, a product manual, an authority having jurisdiction, or a qualified fire, electrical, life-safety, locksmithing, privacy, or security professional.
- How to use this knowledge base
- Scope and boundaries
- Learning paths
- Verification and safety
- Glossary and naming conventions
- Canonical protocol landscape
| Section | Purpose |
|---|---|
| 00 Start here | Orientation, learning paths, scope, terminology, and safe use |
| 01 Foundations | Architecture, networking, media, identity, time, field wiring, reliability, and trust |
| 02 Protocols | Protocol families, wire behaviour, security properties, and implementation concerns |
| 03 Systems | Cameras, VMS, PACS, alarms, intercoms, PSIM, BMS, SCADA, and identity systems |
| 04 Vendor APIs | Publicly documented vendor interfaces with explicit product/version limits |
| 05 Development and integration | Adapter design, event processing, schemas, resilience, and language guidance |
| 06 Security and assurance | Threat modelling, hardening, certificates, API security, privacy, and assurance |
| 07 Operations and lifecycle | Commissioning, inventory, monitoring, backup, incident handling, and retirement |
| 08 Defensive labs | Synthetic, offline, tabletop, calculation, and loopback-simulation exercises |
| 09 Reference | Matrices, ports, statuses, glossary, and quick-reference material |
Every substantive page carries YAML metadata and a verification state:
| State | Meaning |
|---|---|
V0 |
Draft, incomplete, or containing unresolved material claims |
V1 |
Material claims checked against primary sources for the stated coverage |
V2 |
Primary-source checked, cross-checked where practical, and statically reviewed |
V3 |
Environment validated for an exact claim in a recorded evidence set |
V2 does not mean product conformance, interoperability, regulatory approval, or successful execution. V3 requires a linked, narrowly scoped evidence record reviewed under the verification policy.
- Treat commands, payloads, and code as explanatory unless their page says otherwise.
- Never aim exploratory traffic at a system without written authorization and an agreed test window.
- Keep door, gate, lift, fire, alarm, relay, lockdown, and emergency-control work non-actuating until it has passed the site's engineering and safety process.
- Use synthetic identities, documentation address ranges,
.examplenames, and secret placeholders. - Prefer observation, vendor-supported diagnostics, and reversible changes. Preserve evidence and an independent recovery path.
The source and status baseline was reviewed on 2026-08-25. Time-sensitive highlights, including ONVIF Profile V's Release Candidate status and Profile S's scheduled support end, are dated and linked in the landscape. The original dated landscape filename remains as a navigation-only compatibility pointer. Consult the relevant standard, conformance database, product documentation, and advisories before making a deployment decision.
open~knowledge 2026 tegridydev.
Unless otherwise noted, original repository prose, metadata, diagrams, tables, examples, and code snippets are available under the MIT License. Vendor names, trademarks, standards, specifications, quotations, and linked third-party materials remain the property of their respective rights holders and are not relicensed by this repository.