Identity, authentication, and authorisation controls
Review identities, authentication methods and permissions across devices, operators and services. Include credential changes, denied operations and account removal in the checks.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Research and static guidance only; product and deployment specific behaviour requires controlled environment validation and authoritative product evidence.
On this page
Overview#
Physical security systems contain several identity types that must not be collapsed into one account model: people, presented credentials, doors and devices, services, workloads, operators, administrators, installers, tenants, sites, and vendors.
The foundation page Identity, authentication, and authorisation defines the canonical conceptual model. The assurance controls here cover identity classes, token/session handling, command permissions, broker/API policy, and audit.
Separate the decisions#
| Decision | Question | Common failure |
|---|---|---|
| Identification | Which subject or component is making the request? | Treating a card number, IP address, topic, or serial address as proof of identity |
| Authentication | What evidence binds the claimant to that identity now? | Shared defaults, unvalidated certificates, reusable bearer material |
| Authorisation | May this identity perform this action on this object in this state? | Equating successful login or network reachability with permission |
| Accounting | Can the decision and outcome be reconstructed? | Shared accounts, missing correlation IDs, mutable or unsynchronized logs |
Identity classes#
- Human workforce identity: managed through an authoritative joiner mover leaver process.
- Physical credential: a token or mobile credential linked to a person or role; the identifier alone may not be secret or authentic.
- Device identity: preferably a unique key and certificate bound to a device lifecycle, not a shared fleet password.
- Workload identity: unique per service or integration instance, with narrowly scoped API/broker permissions.
- Administrative identity: separate from day to day operator identity, with stronger authentication and audit.
- Break glass identity: controlled, monitored, periodically verified, and designed around safe loss of upstream identity services.
Authorisation model#
Model an authorisation as subject, action, resource, context, and policy version. Context may include site, tenant, door group, alarm partition, device class, time schedule, incident state, dual approval, and command origin. A transport session doesn't make subsequent actions safe automatically.
High impact actions require explicit verbs and audit semantics. Avoid generic write or execute permissions that silently include unlock, disarm, relay activation, configuration reset, firmware change, evidence deletion, or credential issuance.
Token and session guidance#
- Validate issuer, audience, signature, time bounds, intended token type, and required claims.
- Use short lived access tokens and narrowly scoped service credentials; rotate without service wide outages.
- Prevent bearer tokens from entering URLs, logs, trace exports, crash reports, or browser history.
- Bind sessions to appropriate client/device evidence where the supported protocol permits it.
- Reject ambiguous subject or tenant identifiers and stale authorisation caches.
- Define revocation and offline behaviour before relying on cloud issued credentials.
OAuth 2.0 is an authorisation framework; it isn't by itself user authentication. Use OpenID Connect when the application needs standardised identity assertions, and follow the current OAuth security best current practice for flow selection and token handling RFC 9700.
Service and broker permissions#
For MQTT or event brokers, constrain publish and subscribe independently by exact topic hierarchy and tenant/site identity. For web APIs, authorise each object and command server side; never trust a client supplied site, role, or ownership field. For device APIs, distinguish media view, event subscription, health, configuration, firmware, user management, and output control.
Sources#
- NIST 800 63, NIST SP 800-63-4 Digital Identity Guidelines, final July 2025, accessed 25 August 2026.
- RFC 9700, RFC 9700: Best Current Practice for OAuth 2.0 Security, January 2025, accessed 25 August 2026.
- OIDC CORE, OpenID Connect Core 1.0 incorporating errata set 2, accessed 25 August 2026.