Describe the purpose first
Begin with the activities the building must support. Residents need dependable access to their homes; staff need spaces appropriate to their duties; visitors need a clear route to their host. Write these needs in ordinary language before creating access groups in software. Otherwise a supplier’s default groups can quietly become the building’s policy.
Use the principle of least privilege: provide what is reasonably needed, not every permission available. This is not a reason to make residents’ lives unnecessarily restrictive. Discuss legitimate shared-space use, flexible working hours and support arrangements. A policy should distinguish between a sensible boundary and a rule that simply moves inconvenience onto someone else.
Separate the person from the token
A fob, card or mobile credential represents an entitlement but is not the entitlement itself. The ISO/IEC 14443 family concerns proximity contactless cards, while NFC Forum specifications support near-field communication ecosystems. Those labels alone do not establish that a product is suitably secure, interoperable with another system or easy for every resident to use.
Ask how credentials are issued, protected, replaced and withdrawn. Mobile credentials may rely on Bluetooth SIG technology or a device wallet, with different hardware and service dependencies. A smartphone option should come with a practical alternative. Consider device replacement, battery depletion and residents who cannot or do not wish to use a personal phone for building access.
Make issuance a repeatable process
A move-in is a useful moment to confirm the authorised household record, explain permitted routes and demonstrate the entrance. Use a proportionate identity-checking process appropriate to the building’s responsibilities. Avoid collecting copies of identity documents merely because the access software provides an upload field. Document who approves access and who performs the administrative change.
Provide a clear receipt or confirmation without exposing sensitive credential information. Tell residents how to report a lost device, what replacement involves and when assistance is available. Shared household credentials can complicate accountability and replacement, so discuss options openly rather than assuming one approach suits every household. Never display live credential identifiers in public notices or demonstrations.
Bound temporary access thoughtfully
Visitors, carers and contractors have different needs. A short visit may justify a limited invitation; a care arrangement may need predictable access over a longer period. Agree an expiry or review trigger that fits the purpose. Time limits can reduce lingering permissions, but an arbitrary cutoff should not interrupt essential support or leave a resident without an appropriate way home.
For contractors, connect access approval to an actual work authorisation and a named building contact. Decide whether supervision is necessary and how schedule changes are confirmed. Avoid broad, indefinitely shared invitations. Where a system offers recurring access, check calendar behaviour and exceptions so that a convenience setting does not become an unnoticed permanent entitlement.
Protect administration as carefully as entry
Someone who can change permissions holds a different kind of access. Separate routine credential tasks from unrestricted system administration where practical, and avoid shared administrator accounts. FIDO Alliance standards can support phishing-resistant authentication in compatible management services. Suitability depends on the actual implementation and recovery arrangements, not the presence of a logo.
The National Cyber Security Centre provides useful guidance on account protection and secure administration. Use strong authentication, named responsibilities and an approval trail for consequential changes. A second review can help with unusually broad permissions. Staff also need a safe way to report mistakes without delaying corrective action out of concern about blame.
Withdraw access and review the evidence
A move-out, lost token or staff departure should trigger a defined process, including confirmation that the change has reached the relevant controllers. If a controller is offline, immediate remote revocation may not be possible. Understand that limitation in advance and agree an authorised response with the system provider. Do not equate a saved dashboard change with a completed door-level update.
Access logs should answer defined operational questions, not become a general record of residents’ habits. Restrict who can inspect them, set justified retention periods and explain the process for legitimate requests. The Information Commissioner’s Office offers UK data-protection guidance. Review active permissions as well as events: removing unnecessary access can be more useful than storing ever more history.