Modern Security Solutions for BC Strata Corporations

Ryan Grant introduces Subhan Vohra and frames the conversation around a question facing many BC strata corporations: what can a modern security upgrade do beyond replacing worn-out equipment? Subhan describes WeTech’s work across video intercom, access control, CCTV and parkade entry, with an emphasis on systems that can be managed without a dedicated computer in the building.

The episode is a live product-and-workflow demonstration rather than a comparison of every product in the market. Viewers should treat it as an example of one available architecture and use it to build a requirements list for their own property.

The first demonstration treats the entrance panel as a connected, configurable device instead of a directory attached to a single telephone number. In the setup shown, a visitor selects a unit and the resident receives a video call, can speak with the visitor and can release an authorized door from the app. The visual check is presented as a way to reduce blind entry decisions when someone claims to be a courier.

The entrance device also supports access-control functions such as card, NFC, Bluetooth and optional face-based credentials. An intercom and credential reader can share a platform while the strata chooses which features to enable. Model, wiring, elevator and door compatibility must still be confirmed for each building.

Subhan shows how a resident or authorized manager could create a credential for someone who should not receive a permanent fob. Examples include a one-time delivery, a guest staying for several days or a cleaning company visiting on a recurring schedule. The demonstrated workflow can limit a code or QR key by time and by selected openings; in a configured building, the visitor’s permitted elevator floor can also be included.

Use of the credential creates an activity record in the portal. The security value comes from narrow permissions and automatic expiry, not from the QR format itself. Councils should decide who may issue visitor credentials, how long records are kept, what happens when a code is shared and how an active credential is revoked.

This chapter addresses a common adoption concern: a building should not require every resident to own or confidently use a smartphone. The demonstrated configuration can send an ordinary voice call to a mobile number or landline, allowing a resident to answer and press a configured key to release the entrance.

A sequence call tries authorized people in order, while a group call alerts several contacts and connects the first person who answers. Residents can choose a preferred arrangement within settings allowed by management. Exact user limits and fallback behaviour are product- and licensing-specific, so they should be verified in a current proposal. A strata should preserve a practical non-app route and assess individual accommodation needs.

The episode distinguishes a resident view of unit activity from a broader manager view and demonstrates visitor image capture associated with entry activity. Subhan describes a cloud-hosted deployment and an on-site server option, noting that the latter adds equipment and maintenance.

A procurement discussion must go beyond the name of the cloud provider. A strata should document exactly what is collected, why it is needed, where it is stored, who can view or export it, how administrator and vendor access is authenticated, when records are deleted and what happens when the contract ends. BC PIPA requires reasonable security and purpose-based retention; cloud hosting does not transfer those responsibilities away from the strata.

The entrance system shown can accept several credential types, including a PIN, phone-based options, QR credentials, facial recognition and a conventional fob. It can also require two different factors in configured situations—for example, a card plus a PIN—rather than treating a shared PIN as sufficient.

Ryan and Subhan discuss a mixed-use building in which residential and commercial groups need different rules. The proposed answer is separate administrative views and feature policies while using shared equipment. Councils should map credential types to risk and usability instead of enabling every method, and should provide an accessible alternative for anyone unable to use the default method.

Subhan demonstrates several ways an authorized user might open a door without searching through an app: tapping a phone through NFC, using a nearby Bluetooth credential with a deliberate phone or hand gesture, presenting a temporary QR key or carrying a separate Bluetooth token. The gesture is shown as a safeguard against a nearby door releasing merely because an authorized device is within range.

The interface can also limit how frequently a credential triggers, reducing repeated releases when someone remains near an entrance. These are convenience patterns, not universal guarantees. Range, device support, accessibility, battery condition, reader placement and false-trigger behaviour should be tested at the actual doors while a fob or other dependable alternative remains available.

The recording shows a fast face-based unlock while the enrolled user wears a hat and describes depth or liveness checks intended to reject a photograph. That is evidence of how the demonstrated equipment behaved in the recorded setup, not a promise that biometric recognition is error-free or appropriate for every building.

A facial template is sensitive personal information. Before considering it, a strata should define a necessary purpose, compare less intrusive alternatives, assess accuracy across affected residents, offer a workable non-biometric route, restrict access to template and event records, and set deletion rules. Vendor anti-spoofing claims should be validated in the proposed model and configuration. A privacy or legal professional should review the actual plan; this guide is not legal advice.

The conversation moves from entrance convenience to an administrative pain point: lost remotes, resident turnover and the time required to locate and delete an old credential. In the portal demonstration, an authorized manager finds a resident record, removes a missing fob, registers a replacement and updates a unit for a new occupant.

Updating the occupant is presented as a way to remove credentials tied to the former resident and send enrolment details to the new one. A sound handover process should still include a reconciled credential inventory, documented approval roles and a check that all old app, fob, remote, PIN and biometric access has been removed. The goal is prompt, auditable deactivation—not merely easier issuance.

For parkade access, the episode demonstrates entering a resident or contractor plate and assigning a validity period. A configured licence-plate recognition camera can use that record to trigger a gate. For long-term resident vehicles, the discussion adds a long-range UHF tag so both the tag and plate must match; temporary contractor access can be time-limited.

A building can grant vehicle access without circulating a permanent remote, but a plate and its time-stamped movements may identify a person. The strata should limit collection and viewing, publish the purpose, set retention and correction procedures, and consider a non-LPR alternative. Lighting, weather, plate changes and manual fallback also belong in acceptance testing.

The manager portal demonstration builds a credential with a name, start and end time, recurrence, permitted number of uses and selected doors, then sends a code or barcode electronically. The same controls can support recurring staff and other approved service providers. Managers can see and revoke temporary keys, and can withdraw a resident’s ability to issue them if the building’s policy is being misused.

The chapter also displays permanent-style emergency-service entries, but a strata should not invent or distribute emergency codes without coordinating the procedure with its fire-safety professionals, local authorities and building plan. For ordinary vendors, use the least access needed, confirm who sponsors the visit, avoid shared permanent credentials and make expiry the default.

Subhan walks through the resident interface: recent activity and calls, temporary-key creation, Bluetooth behaviour, permitted biometric enrolment, family-member invitations, preferred group or sequence calling, app-versus-phone fallback, notification style and basic profile maintenance. Selected council or management users can receive limited ability to register fobs without every administrative permission.

Built-in illustrated help and support links are intended to reduce routine requests to the building manager. The useful design principle is controlled self-service: residents can maintain approved details and preferences, but unit identity, building-wide security rules and sensitive permissions remain with authorized administrators. That boundary should be written into the strata’s access policy, supported by role-based accounts and reviewed when council, managers or occupants change.

The property-management view can link several sites, issue targeted announcements and, where configured, display selected cameras inside the same platform. Messages can be directed to a building, floor or group. Camera viewing can be limited to management or explicitly assigned users. The broader point is consolidation: intercom, door access, gate, elevator permissions, cameras and communications can be administered together and updated remotely.

Consolidation can reduce duplicated work, but it also concentrates authority. Each person should receive only the access required for their role; important administrative accounts should use multi-factor authentication; vendor access should be logged and removable; and camera access should follow a documented privacy purpose rather than being enabled simply because the interface allows it.

The episode gives several examples of an entrance panel acting as a communication surface. A building could let residents opt into a notification when an authorized postal entry occurs, show a building notice or rental message on the panel, or add a button that calls a programmed service. The demonstrated intercom uses IP connectivity rather than a dedicated traditional telephone line.

These extras should not obscure the panel’s primary accessibility and emergency functions. Notices need clear ownership and expiry; call buttons should be labelled and tested; and the network design needs an explicit response to loss of power, local network, internet, DNS, cloud service and telephone routing. The episode does not establish one universal outage outcome.

Subhan describes the commercial model offered at the time of recording as an up-front per-unit licence included in the installation, with internet service still required. He distinguishes resident and manager self-service from an optional paid programming arrangement for buildings that want WeTech to make frequent changes. The rollout described includes an on-site resident session, a later online question-and-answer session and self-help material.

These statements are a useful prompt for a life-cycle quote, not current pricing. A council should obtain written details for hardware, licences, cloud services, connectivity, support hours, remote programming, training, spares, vandalism, warranty, software updates, data export, contract termination and replacement. The responsible comparison is total cost and operational ownership over the expected system life.

The final chapter shows a gate command through Apple CarPlay and Siri, followed by iOS Shortcut examples that place a door action on the home screen or prompt the user near a location. These automations depend on the resident’s device, settings and the integration available at that time; any automatic action should require a deliberate, authenticated confirmation.

Subhan contrasts a like-for-like equipment replacement with an upgrade residents can notice in daily use. A dashboard from one 55+ property is shown as an example of residents using several credential types, with face access leading in that single 30-day snapshot. It is not a benchmark for other communities and should not be used to predict adoption. The episode closes by encouraging councils to evaluate available technology against their own residents, policies and building conditions.