Two Button Elevator Relay Security

Section 28 36 00
Two-Button Elevator Relay Security

Status: Draft Version 1 – Consultant Ready
Basis Of Design: BluB0X BluSKY

Coordinated With:

• Division 14 – Conveying Equipment
• Division 28 – Electronic Safety And Security

Related / Normative References:

• Physical Security Management Platform (PSMP)
• Enterprise Identity, Credentials & Biometrics
• Enterprise Person Reader & Intelligent Edge Devices
• Spatial Intelligence, Mapping & Digital Twin
• Security Intelligence, Orchestration & AI
• System Health, Telemetry & Assurance
• Security Power, Resiliency & OTA Lifecycle
• Section 28 35 00 – Elevator Destination Dispatch Security (DDE)

Part 1 – General

1.1 Summary
A. This section defines requirements for secure elevator access control using two-button (non-destination dispatch) elevator systems, in which elevator car assignment and movement are non-deterministic.

B. Security enforcement shall be performed through relay-based enable/disable control of elevator call buttons and floor selection, after occupants enter the elevator car.

C. This specification applies to:
• Legacy elevator systems
• Retrofit environments
• Buildings not equipped with destination dispatch

1.2 Purpose And Intent
A. Provide identity-centric elevator security in two-button environments.
B. Enforce floor authorization without interfering with elevator OEM safety systems.
C. Support enterprise-grade redundancy, diagnostics, and auditing.
D. Enable phased migration to destination dispatch and hybrid elevator security models.

1.3 Definitions
• Two-Button Elevator: Elevator system using up/down hall calls and in-car floor buttons
• Relay Security: Authorization enforced via electrical enable/disable of buttons or circuits
• Floor Stop: Logical security object representing an elevator destination
• Non-Deterministic Dispatch: Elevator assignment not known prior to car entry

Part 2 – System Description

2.1 Two-Button Security Model
A. Occupants:
• Enter the elevator car without declaring destination
• Select destination using in-car buttons

B. Security enforcement occurs by:
• Enabling authorized floor buttons
• Disabling unauthorized floor buttons

C. Elevator motion, dispatch logic, leveling, and safety remain under OEM control.

2.2 Relationship To Other Elevator Models
A. Destination dispatch security is specified in Section 28 35 00.
B. Hybrid elevator security (two-button + destination dispatch) is specified separately.
C. This specification shall not assume deterministic dispatch behavior.

Part 3 – Architecture, Resilience, And Redundancy

3.1 Redundant Elevator Security Processing
A. All elevator relay security controllers, processors, or servers shall be fully redundant.
B. Redundancy shall include:
• Elevator relay controllers
• Security processing services
• Network interfaces

C. Redundant systems shall operate with automatic failover, requiring no operator action.

3.2 Single-IP OEM Constraint And Failover
A. Where elevator OEM interfaces accept communication from only one IP address, the system shall:
• Present a single, fixed IP address to the elevator system
• Maintain that IP through automatic failover

B. Failover shall be implemented using:
• Network-level IP ownership transfer
• Transparent switching between redundant processors

C. The elevator system shall never observe an IP change.

3.3 Failover Performance
A. Failover shall occur within thresholds suitable for continuous elevator operation.
B. During failover:
• Elevator safety shall not be impacted
• Relay logic shall revert to configured fallback behavior if required

Part 4 – Identity And Credential Support

4.1 Identity-Centric Authorization
A. Floor access shall be authorized based on identity, not device alone.
B. Authorization shall be evaluated using:
• Identity attributes
• Access levels
• Schedules
• Context (location, time, role)

4.2 Universal Credential Support
The system shall support all credential types, including:
• Facial recognition
• Voice recognition
• Name or identity lookup
• PINs
• QR codes
• Mobile/cloud credentials
• Apple Wallet credentials
• Google Wallet credentials
• Bluetooth credentials
• All common proximity card formats

4.3 Visitor And Temporary Credentials
A. Visitor credentials shall be supported, including:
• Pre-registered visitors
• QR-based credentials
• Time-limited mobile credentials

B. Visitor access shall support:
• Floor-level authorization
• Escort / two-card logic
• Automatic expiration

Part 5 – Floor Matrix And Access Policy

5.1 Floor Stops As Security Objects
A. Each elevator floor shall be treated as a logical access control object.
B. Floor stops shall support:
• Secured state
• Public state
• Unavailable state

5.2 Floor Matrix Application
A. A Floor Matrix shall define:
• Authorized floors per identity
• Schedule-based access
• Offline behavior

B. The Floor Matrix shall be evaluated:
• Prior to enabling in-car buttons
• During schedule changes
• During degraded operation

5.3 Schedules And Offline Behavior
A. Floor access may change based on:
• Time of day
• Day of week
• Holidays
• Offline state

B. Offline behavior shall be explicitly configurable and auditable.

Part 6 – Access Workflows

6.1 Lobby-Based Authorization
A. Authorization may occur prior to car entry using:
• Card readers
• Person Readers
• Kiosks
• Mobile credentials

B. Upon authorization:
• Elevator call buttons or in-car buttons shall be enabled accordingly.

6.2 In-Car Floor Enablement
A. When a user enters the car:
• Authorized floor buttons shall be enabled
• Unauthorized floor buttons shall remain disabled

B. Authorization shall persist only for the duration of the ride or configured time window.

6.3 Escort And Two-Card Logic
A. Two-card (escort) logic shall be supported for restricted floors.
B. Escort rules shall be:
• Policy-driven
• Time-limited
• Fully auditable

Part 7 – Person Readers And Kiosks (Relay Context)

7.1 Person Reader Integration
A. Person Readers may be used to:
• Authenticate identity
• Enable authorized floors
• Capture proof of presence

B. Person Readers shall support:
• Multi-modal identity
• Touchless interaction
• Visitor processing

7.2 Kiosk And Turnstile Integration
A. Relay authorization may be triggered by:
• Lobby kiosks
• Turnstile-integrated terminals
• Upper-floor kiosks

B. Turnstile-based authorization shall coordinate with:
• Anti-passback
• Tailgating detection

Part 8 – Operator Control And Overrides

8.1 Real-Time Floor Control
Authorized operators shall be able to:
• Lock floors
• Unlock floors
• Temporarily release floors
• Revert floors to schedule

8.2 Access Modes
Supported access modes shall include:
• Card only
• PIN only
• Card + PIN
• Card or PIN
• Two-card (escort) mode

8.3 Credential Simulation
A. Operators may simulate credential presentation for testing.
B. Simulations shall:
• Not move elevator cars
• Be clearly logged as test actions

Part 9 – Diagnostics And Commissioning

9.1 Relay Diagnostics
Diagnostics shall support:
• Testing floor relays
• Verifying enable/disable logic
• Validating Floor Matrix application

9.2 Remote Troubleshooting
A. Diagnostics shall support:
• Remote commissioning
• Off-site troubleshooting
• Validation after configuration changes

Part 10 – Eventing, Audit, And Compliance

10.1 Access Events
All floor enable/disable actions shall generate events including:
• Identity
• Floor
• Action performed
• Timestamp

10.2 Override And Diagnostic Events
Manual overrides, releases, and simulations shall be logged and auditable.

Part 11 – Safety And Code Compliance

A. Elevator OEM safety systems shall always take precedence.
B. Security system shall never:
• Trap occupants
• Override emergency modes
• Interfere with fire service or life-safety operation

Part 12 – Migration And Hybrid Readiness

12.1 Migration To Destination Dispatch
A. Architecture shall support phased migration to DDE.
B. Identity, Floor Matrix, and diagnostics shall be reusable.

12.2 Hybrid Coordination
A. Relay security shall coexist with DDE security in hybrid deployments.
B. Conflicts shall be resolved through defined priority rules.

Part 13 – Submittals And Close-Out

• Relay architecture diagrams
• Floor authorization matrices
• Wiring and interface documentation
• Commissioning and diagnostics reports

Part 14 – Acceptable Manufacturers

14.1 Basis Of Design
Managed through the Physical Security Management Platform with OEM-agnostic relay integration.

14.2 Acceptable Alternatives
Alternative systems shall meet all requirements of this specification.

End Of Section 28 36 00