Planning Access Control for Elevators and Parking Areas

A resident, tenant or visitor can present a valid credential at the parking gate and still face a denied elevator floor, an unclear pedestrian route or an after-hours lockout. The reverse problem is equally serious: a vehicle follows through an open gate, then a person reaches the elevator lobby through a poorly defined transfer point. These concerns appear repeatedly in public Toronto discussions about condo and mixed-use access, although those anecdotes do not measure how often failures occur.

The practical answer is to plan one complete journey, from the vehicle entrance to the authorized floor and back out. Build a permission matrix for every gate, door and elevator destination; preserve the building’s approved emergency and egress operation; assign each interface to a named party; and commission the full route under normal, denied and failed-system conditions. This gives property and facilities managers a defensible basis for coordinating commercial access control across multiple building systems.

1. Map the complete journey before selecting equipment

Start with the people and journeys the property must support. Draw each route on the current site and building plans, including every place where vehicle access becomes pedestrian access.

At minimum, map:

• a tenant or resident arriving through the parking gate and travelling to an approved floor;
• a visitor using visitor parking, intercom or registration, elevator access and a return route;
• a delivery or service contractor reaching a loading or parking area and a limited destination;
• a property operator travelling between parking, service rooms and tenant areas;
• an accessibility route from vehicle arrival to the elevator and destination;
• an after-hours route when reception, concierge or parking staff are unavailable; and
• an emergency or degraded route during power, network, controller or elevator-service interruption.

Mark the vehicle gate, pedestrian lobby door, elevator reader, permitted floors, stair re-entry points, loading areas and any second resident or tenant boundary. A floor restriction in the elevator does not resolve a bypass through a stairwell, a held door or a shared mixed-use parking level. The route map should reveal those transitions before a vendor prices readers and relays.

Give every boundary a purpose. The outer gate may separate the public road from controlled parking. A second gate or pedestrian door may separate public visitor parking from resident or tenant areas. Elevator permissions may limit vertical travel after entry. When two controls have the same purpose, decide whether the extra credential presentation adds meaningful protection or simply encourages door holding and workarounds.

2. Build one permission matrix for gates, doors and floors

Translate the route map into a matrix that answers who can go where, when, by which route and under whose approval. Elevator access platforms often model each floor as an access point. Genetec’s official elevator administration documentation describes floor outputs, optional tracking inputs and credential-controlled floor selection. Its related access-rule guidance shows that rules and schedules determine who may use controlled floors and when. These are product-specific examples, so the selected platform and elevator interface must be verified directly.

Use role-based permissions rather than adding exceptions person by person:

User journey	Vehicle area	Pedestrian transfer	Elevator destination	Schedule and expiry
Tenant or resident	Assigned parking zone	Approved garage lobby	Home, suite and approved amenities	Occupancy term and approved hours
Visitor	Registered visitor area	Hosted or intercom-approved route	Host floor only, where supported	Short visit window with automatic expiry
Contractor	Work-order parking or loading	Defined service route	Work floor and required service area	Task window with sponsor and expiry
Property operations	Operational parking and service areas	Building service route	Approved operating floors	Role schedule with reviewed exceptions
Emergency responder	Approved response route	Life-safety procedure	Required emergency operation	Governed by approved emergency procedures

Record the credential type, approving role, system of record, automatic expiry, alarm response and audit owner for each row. Include the return trip. A visitor who can reach a destination may still need a controlled way back to the correct parking level without gaining access to unrelated floors.

Avoid a single broad group such as “all parking and elevators.” Separate vehicle eligibility, pedestrian-zone access and floor eligibility so a change to one does not silently expand the others. If the platform supports inheritance, document which new gates, floors or amenities could be added to an existing group and require review before activation.

3. Assign every interface to a named owner

The difficult failures often occur between contracts. The access integrator may provide readers and controllers, the elevator contractor may provide an approved interface, the parking vendor may own gate controls, and property operations may own visitor policy. Assign one accountable property lead and a clear deliverable to every participant.

Party	Required ownership evidence
Property or facilities lead	Approved journeys, permission matrix, operating procedures and final acceptance record
Access-control integrator	Controller design, floor and gate logic, credential rules, event reporting and as-built configuration
Elevator contractor	Approved elevator interface, operational limits, emergency interaction and required testing or inspection coordination
Parking-gate provider	Operator, detection and safety-device design, lane logic, manual operation and maintenance procedure
Fire-alarm or life-safety parties	Confirmation that access logic preserves the approved fire and emergency sequences
IT and cybersecurity team	Network segmentation, power, monitoring, backups, accounts and recovery responsibilities
Privacy or records owner	Permitted credential data, log access, retention, exports and service-provider access

TSSA states in its elevating-device inspection guidance that it inspects new, existing and altered elevating devices in Ontario and classifies covered alterations under the adopted elevator and lift codes. Do not assume that adding floor control is outside elevator scope. Have the licensed elevator contractor determine the proposed work, required submissions and inspection path with TSSA before installation.

The interface schedule should identify every input, output, relay, protocol, controller, power supply and responsible party. It should also state who may change the elevator access logic after handover. A software administrator should not be able to alter an approved life-safety sequence through an ordinary access-rule change.

4. Separate normal access from elevator emergency operation

Normal elevator access rules answer which credential may enable which floor. Elevator recall, firefighter operation, emergency power and other approved sequences follow the building’s elevator and life-safety design. Document both sets of behaviour and the boundary between them.

Ontario’s current Fire Code, O. Reg. 213/07 includes requirements for maintaining and testing fire emergency systems in applicable buildings, keeping required elevator recall and independent-operation keys in the prescribed location, and keeping specified egress doors readily openable from the inside under the conditions stated in the regulation. Application depends on the building, occupancy, approved design and authority having jurisdiction.

For each controlled gate, door and elevator interface, record:

• normal authorized and denied behaviour;
• fire-alarm and elevator-recall behaviour;
• emergency-power behaviour;
• loss-of-power behaviour for the access layer;
• loss of network, server or controller communication;
• manual operator and firefighter procedures;
• accessibility implications; and
• the party authorized to restore normal operation.

Keep the access-control commissioning plan aligned with the building’s approved fire safety plan and elevator documentation. A generic “unlock on alarm” note is insufficient because the correct sequence varies by opening, elevator system and building design. Use qualified parties to establish and witness the actual requirements.

5. Treat parking-gate safety and security as separate tests

A gate must authorize vehicles while preserving the operator’s approved safety functions. Security pressure should never lead to unsafe closing times, defeated detection or a pedestrian route through the moving gate.

HySecurity’s official entrapment-protection guide emphasizes site assessment, entrapment-zone drawings and external sensors for applicable automated gates. It is manufacturer guidance based on a United States standard, so it does not establish Ontario compliance. It does illustrate why the gate operator, vehicle loops, photo eyes, edges and access device must be reviewed as one site-specific system.

Reduce tailgating through layered operating choices:

1. Provide a clear, protected pedestrian path that does not rely on the vehicle gate.
2. Use lane geometry and detection appropriate to the gate type and traffic pattern.
3. Separate public visitor parking from resident, tenant or service areas when the risk assessment supports a second boundary.
4. Configure safe gate timing with the gate specialist, then observe real vehicle behaviour before acceptance.
5. Give operators a defined response to forced entry, a held gate or a vehicle following too closely.
6. Review video or event records only for an approved purpose and within the property’s retention policy.

Test an authorized vehicle, an unauthorized vehicle, a vehicle stopping in the detection zone, two vehicles arriving close together, a pedestrian near the lane and loss of power. Record the physical gate behaviour and the access event separately. A successful credential read does not prove safe movement, and a safe gate cycle does not prove the correct permission was applied.

6. Design visitor, delivery and after-hours routes explicitly

Visitor access is often where otherwise sound designs become inconvenient or overly broad. Decide how a host, concierge or building operator approves the visit, where the visitor parks, how the person enters the pedestrian lobby, which floor becomes available, how long access lasts and how the visitor exits.

Use the smallest permission that supports the visit. Where the technology permits, link a visitor to one parking authorization, one transfer route and one destination floor for a defined period. Deliveries and contractors need separate rules because their sponsor, loading route, equipment and work hours differ.

Write procedures for exceptions:

• the host does not answer;
• the intercom or visitor system is offline;
• reception is closed;
• a credential was issued to the wrong destination;
• the visitor parks on the wrong level;
• the elevator is out of service;
• the accessible route is unavailable; or
• the visit extends beyond the original expiry.

The operator should be able to resolve an exception without granting unrestricted floors or sharing a master credential. Include a named escalation contact and a record of who approved any temporary expansion.

7. Plan for lockouts, outages and stale permissions

Legitimate users can be denied by an expired group, a data-synchronization error, a failed reader, a disabled elevator interface or an incomplete tenant change. Define how the property distinguishes a bad credential from a failed subsystem.

Create a degraded-operation table:

Failure	Expected system state	Operator action	Restoration evidence
Access server or network unavailable	Documented controller and elevator-interface behaviour continues or fails as designed	Confirm local status and follow approved offline procedure	Health restored and representative route retested
Parking reader unavailable	Gate remains in approved safe state	Direct vehicles to the approved alternative or manual process	Reader, detection and event reporting retested
Elevator interface unavailable	Elevator follows approved operational and emergency design	Contact elevator contractor and apply building procedure	Interface and floor permissions witnessed
Visitor platform unavailable	No broad credentials issued by default	Use approved manual registration and escort path	Temporary records reconciled and access closed
Credential wrongly disabled	Identity and authority verified through a separate process	Authorized operator restores only approved groups	Change recorded and root cause reviewed

Review credentials at tenant move-in, role change, parking reassignment, lease expiry and move-out. Automatic expiry reduces stale access, but the property still needs a tested correction path. Notify affected users when planned changes will alter their route, and give operators a script for verifying authority without collecting unnecessary personal information.

8. Limit identity data and access-event exposure

Parking and elevator logs can connect an identity or credential to places and times. Collect the fields needed for the operating purpose, limit who can search or export events and document retention.

The Office of the Privacy Commissioner of Canada’s identification and authentication guidelines advise organizations to minimize identity attributes, select authentication strength according to risk, maintain appropriate records and remain accountable when identity management is outsourced. Applicability depends on the organization, relationship, purpose and governing privacy law.

Apply those principles by:

• using role and destination data without extra identity attributes where practical;
• separating routine operators from administrators and export privileges;
• using named accounts for permission changes;
• defining a purpose and approval path for parking and elevator event reviews;
• limiting vendor support access and closing it after service;
• setting retention for active credentials, expired visitors and event logs; and
• testing that one tenant administrator cannot view another tenant’s users or movements.

If licence-plate recognition, mobile credentials or biometrics are proposed, conduct a separate necessity, proportionality, security and privacy review. Those technologies change the data and risk profile beyond basic credential coordination.

9. Commission the full route with acceptance tests

Test journeys instead of isolated devices. Record the expected result, actual result, time, tester, observed access event and corrective action.

Acceptance test	Expected evidence
Authorized tenant arrives during approved hours	Gate opens safely, pedestrian door grants access and only approved elevator floors become available
Same credential is used outside schedule	Defined points deny access and generate the expected operator event
Visitor follows the approved workflow	Parking, transfer door, destination floor and return route work only for the approved period
Vehicle follows closely behind an authorized vehicle	Gate safety remains intact and the security response follows the documented procedure
User attempts an unapproved floor	Floor remains unavailable and the event is recorded as configured
Stair or alternate route is checked	No unintended bypass defeats the planned boundary
Network or server connection is interrupted	Controllers, gates and elevator access behave according to the documented offline design
Power is interrupted and restored	Approved gate, door and elevator behaviours occur and normal rules recover correctly
Fire and elevator emergency sequence is witnessed	Normal access restrictions do not interfere with the approved sequence
Credential is disabled or expires	Parking, pedestrian and elevator permissions all close as specified
Tenant administrator searches another tenant	Other tenant users and events remain outside the administrator’s scope

Witness the tests with the parties who own each interface. Resolve failures, repeat affected scenarios and attach the results to the as-built documentation. Re-run the route tests after elevator modernization, access-platform upgrades, parking changes, tenant reconfiguration or changes to emergency sequences.

10. Ask vendors questions that expose coordination gaps

Use procurement questions that require evidence instead of assurances:

• Which exact gates, doors and elevator floors does each role receive, and where is that matrix documented?
• Is the elevator integration relay-based, protocol-based or destination-dispatch integrated, and what are its limitations?
• Which party supplies, installs, programs and tests each interface point?
• Has the elevator contractor determined the TSSA submission and inspection implications?
• What happens at each device during network, server, controller and power failure?
• How are fire recall, firefighter operation, egress and emergency-power sequences protected from ordinary access-rule changes?
• How are visitors linked from parking registration to a limited floor and back to the garage?
• Which gate safety devices and detection zones are included, and who performs the site assessment?
• Can temporary permissions expire automatically across parking, doors and floors?
• Can operators diagnose which subsystem caused a denial without broad administrator access?
• What logs are retained, who may export them and how is vendor support access controlled?
• Which end-to-end tests, drawings, configuration backups and operating procedures are delivered at handover?

Ask the bidders to demonstrate a normal tenant journey, a visitor journey, a denied destination and one degraded scenario. Include the accepted matrix, interface schedule, failure table and test record in the contract deliverables.

Coordinated planning lets parking, pedestrian and vertical access work as one operating system while preserving each building system’s approved function. Securitron Canada can help GTA property teams document journeys, define interfaces and commission practical commercial property management security controls.