| Credential Security | How access credentials are created, stored, revoked, and recovered. | Unique credentials for each user; immediate revocation; no shared administrator password. | Passkeys or phishing-resistant MFA for administrative access, role-based permissions, and time-limited guest credentials. | Emergency credentials should be individually assigned, auditable, and automatically expire when possible. | 20% |
| Encryption and Communications | Protection of data moving between the lock, mobile device, hub, and cloud service. | Encrypted communications using current, vendor-documented protocols; rejected or deprecated encryption must not be used. | End-to-end protection where practical, authenticated device pairing, key rotation, and secure handling of cryptographic keys. | Offline emergency methods must not expose permanent credentials through an unprotected wireless connection. | 15% |
| Software Updates | How firmware and mobile applications are patched and verified. | Documented security-update process, signed firmware, update notifications, and a stated support period. | Automatic security updates with signature verification, rollback protection, vulnerability reporting, and published end-of-support dates. | The lock should remain usable through a safe fallback method if an update fails or connectivity is unavailable. | 15% |
| Privacy Controls | What personal data is collected, why it is collected, and who can access it. | Clear privacy notice, data minimization, account deletion process, and controls for sharing access logs. | Local processing where feasible, configurable retention periods, export and deletion tools, and no precise location collection by default. | Emergency events should record only necessary details and should be visible to authorized users through an audit trail. | 15% |
| Auditability | Whether access attempts and administrative changes can be reviewed. | Timestamped records for successful and failed access attempts, credential changes, and administrator actions. | Tamper-evident logs with synchronized time, export capability, configurable retention, and alerts for repeated failed attempts. | Emergency openings should be clearly labeled in the log and linked to the credential or method used. | 10% |
| Emergency Entry | How authorized people can enter during a dead battery, network outage, lost phone, or account lockout. | At least one documented backup method, such as a mechanical key, external power input, local keypad, or offline credential. | Two independent fallback methods, tested regularly, with controlled issuance and no permanently shared emergency code. | Confirm that the backup method works without internet access and that emergency use does not permanently disable normal security controls. | 15% |
| Power and Connectivity Resilience | Expected behavior during low battery, power loss, Wi-Fi failure, Bluetooth failure, or cloud outage. | Low-battery warnings, predictable fail-secure or fail-safe behavior, and documented offline operating limits. | Multiple warning stages, local access operation during temporary outages, protected battery compartment, and a clearly tested recovery procedure. | Verify the exact remaining battery warning time and test external power or mechanical override before installation. | 10% |
| Physical Protection | Resistance to forced entry, tampering, drilling, bypass attempts, and incorrect installation. | Suitable cylinder, strike plate, mounting hardware, door alignment, and installation instructions for the specific door. | Independent security testing, tamper detection, protected internal wiring, hardened mounting points, and compatibility with the door’s security rating. | Emergency hardware should be accessible to authorized responders without creating an obvious attack path. | 10% |
| Interoperability and Administration | Compatibility with existing doors, access systems, mobile platforms, and identity-management procedures. | Documented compatibility requirements, supported operating systems, local reset procedure, and clear administrator roles. | Standards-based integration, least-privilege permissions, multi-user administration, and an exportable configuration or audit record. | At least two trained administrators should be able to manage recovery without relying on one person’s private account. | 10% |