Mobile Access Control: How It Works for Properties

 

 

For a property team, replacing or supplementing keys and fobs with phones can sound simple. The real decision is more detailed: Which doors support which credential, how will access be revoked, what happens when a phone fails, and what will people use if they cannot or do not want to use a smartphone?

Mobile access control uses a smartphone-based credential, a compatible reader, an access controller or cloud service, and connected entry hardware to verify permission and release an entry point. It can support a building door, gate, garage, amenity space, elevator, or other configured access point. But the experience depends on the credential method and the property setup. This guide explains how to compare those choices and build a practical rollout plan.

This guide will answer:

• What mobile access control is and what it requires
• How a mobile credential opens an entry point
• Which credential method fits each property use
• Map credentials to entry points and users
• How secure mobile access really is
• When phones connectivity or power fail
• Combine mobile access with cards and fobs
• Resident guest delivery and staff workflows
• Evaluate costs governance and fit
• Where ButterflyMX fits in a phased rollout
• FAQs

 

Watch how ButterflyMX works:

 

What mobile access control is and what it requires

Mobile access control is physical access control that uses a phone as a credential. It is different from mobile device management or remote access to a computer system. The purpose here is to verify that a person can enter a physical place at a particular time.

A working system has four connected parts:

• A mobile credential, such as an app credential, NFC wallet key, or temporary visitor pass.
• A compatible access control reader that receives or reads the credential.
• A controller or cloud-managed access service that applies permissions.
• Entry hardware, such as a connected door lock, gate control, elevator access control, or amenity door.

The basic path is phone credential to reader to controller or cloud service to entry hardware. A manager may issue, change, expire, or revoke permissions digitally, but the exact path of verification and the connectivity needed can differ by product and credential type. Not every phone, reader, or entry point supports every method.

 

How a mobile credential opens an entry point

A mobile credential is not just a digital key. It has a lifecycle that starts before a person reaches the door and continues after they move out, change devices, or lose a phone.

1. An authorized administrator assigns access permissions for a user, entry point, and, where needed, a time window.
2. The user activates a credential through the supported app, wallet, link, or other enrollment flow. Some systems bind a credential to a particular device.
3. At the entry point, the user performs the required action. That may be tapping in an app, tapping an NFC wallet key, approaching a supported proximity reader, or presenting a temporary credential.
4. The reader and controller determine whether the credential is valid for that door and time. If it is, the system signals the connected entry hardware to release access.
5. The system can record the event and later support permission changes, expiration, replacement, or remote revocation.

It is useful to separate local phone-to-reader communication from cloud-managed actions. A phone may communicate locally with a reader in one design, while remote unlocks, new permissions, audit logs, and updates can have different network dependencies. Do not assume that verification always happens locally or always happens in the cloud.

 

Which credential method fits each property use

The right credential is a planning decision, not a ranking contest. Compare how people use it, what hardware and connectivity it requires, how it is protected, and what should happen when the normal method is unavailable.

Credential method	How users present access	Connectivity questions to verify	Security and continuity considerations	Property use
App-based BLE	Use an app action or a supported proximity workflow.	Confirm whether phone-to-reader use is local and which issuance, update, or remote functions need internet access.	Deliberate user action and passive proximity have different risk models.	Ongoing resident or staff access with compatible readers and support workflows.
NFC wallet key	Tap a compatible phone or watch at a supported reader.	Confirm device, wallet, reader, provisioning, and replacement support.	Express Mode may permit use without unlocking. Some supported iPhone items can have limited power-reserve use.	Recurring resident or staff access where a wallet interaction is supported.
QR code or visitor link	Present a temporary code, link, or pass through a supported workflow.	Confirm delivery, validation, expiration, and reader or intercom requirements.	Set clear rules for duration, reuse, sharing, and revocation.	Guests, couriers, vendors, and other short-term users.
UWB or secure ranging	Use a supported phone and reader that measure proximity or distance.	Confirm current phone, reader, operating-system, and implementation support.	Ranging can help address relay concerns, but adoption and implementation vary.	Potential hands-free scenarios with verified support.
PIN	Enter a code at a compatible keypad.	Confirm keypad, code-management, update, and outage behavior.	Provides a non-phone route, but codes need issuance, sharing, rotation, and revocation policies.	Fallback access and users without a compatible smartphone.
Card or fob	Present a physical credential to a compatible reader.	Audit credential technology, reader, controller, and wiring compatibility.	Security varies by credential technology. Physical credentials can preserve continuity during migration.	Hybrid deployment, accessibility planning, and non-phone users.

An app-based credential and a wallet key are not the same thing. An app may use Bluetooth Low Energy, or BLE, and may require an in-app action or a supported proximity experience. An NFC wallet key is presented by tapping a compatible device at a supported reader. Apple documents multifamily home keys for supported partner properties, including access to building, unit, and common areas through supported provisioning paths. Read Apple documentation on access key types for the platform-level model.

Temporary visitor links, QR codes, and passes should also be treated differently from a resident credential. A visitor needs a limited purpose, allowed entry points, a start and end time, and a clear issuer. A resident needs an ongoing lifecycle that includes onboarding, device changes, and move-out revocation.

 

Map credentials to entry points and users

Properties rarely need one credential for everyone. A better approach is to create an entry-point and user matrix before selecting a configuration. List each lobby door, gate, garage, elevator, amenity, unit, package area, and other controlled entrance. Then list residents, staff, guests, delivery personnel, vendors, and contractors.

Entry point or user need	Planning question	Possible credential approach	Fallback and owner
Resident lobby and amenities	Does the resident need daily access on a phone, watch, or physical credential?	App, supported wallet key, card, or fob.	PIN, card, fob, or property support process.
Staff and on-site teams	Which areas and schedules apply to each role?	Role-based mobile or physical credential.	Administrator handles changes and urgent replacement.
Guests and deliveries	Who issues access and when does it expire?	Purpose-built temporary pass or visitor workflow.	Intercom or staffed procedure where configured.
Vendors and contractors	Which areas are needed, and for how long?	Time-bound credential with limited access.	Property team approves, monitors, and revokes.

This matrix prevents a common mistake: assuming one credential should open every entry point for every person. The answer depends on reader compatibility, permissions, wiring, controller configuration, and the management workflow.

For example, ButterflyMX documents Wallet Pass support on specified compatible intercoms and Keypad, Single Gang, and Mullion readers. Its Apple and Google Wallet integration guidance is useful for understanding activation, device, replacement, and revocation rules. It is not a substitute for a property-specific matrix covering every gate, garage, elevator, door, and amenity.

Explore how ButterflyMX supports mobile and wallet access across compatible property entry points after you have defined the entry points, credential types, and fallback path each group needs.

 

How secure mobile access really is

Mobile access control can provide strong controls, but it is not automatically more secure than every card or fob. Security depends on the credential being replaced, device binding, the required user interaction, reader design, revocation practices, and the overall system configuration.

 

Interaction changes the security question

A deliberate tap or in-app action is different from passive hands-free Bluetooth proximity. Apple says supported Express Mode cards, passes, and keys can work without waking or unlocking an iPhone. That is convenient, but it also means properties should not assume every wallet interaction requires a biometric check or passcode. Apple also notes that Express Mode availability depends on the supported item and device. See Apple guidance on Express Mode for its current platform behavior.

Passive Bluetooth proximity deserves its own review. NCC Group demonstrated BLE relay risks in systems that treat Bluetooth proximity as proof that a user is physically nearby. The research does not test ButterflyMX products, and it does not mean all mobile access is unsafe. It shows why buyers should ask whether a system requires deliberate action, how it verifies proximity, and how it handles lost or compromised devices.

Secure ranging is one possible way to strengthen proximity verification. Bluetooth Channel Sounding is a ranging capability intended to help counter relay attacks, according to the Bluetooth SIG overview of Channel Sounding. Current support across phones and access readers varies, so it should not be assumed in a property design without confirmation.

 

Revocation and privacy matter too

Fast revocation and access logs can improve control when a phone is lost or a resident moves out. They also create governance duties. Properties should decide which administrators can view or change access, how long records are kept, how residents are informed, and how requests or disputes are handled. These are operational policy choices, not just technology settings.

 

When phones connectivity or power fail

There is no single answer to whether mobile access works without internet. A local BLE or NFC interaction, a remote unlock, a newly issued credential, and a system-wide service interruption are different events. Ask the vendor to describe the specific reader, controller, credential, and outage scenario rather than accepting a broad offline claim.

Situation	What the property should plan
Lost phone	Revoke the mobile credential promptly, remove device access where available, provide a temporary fallback, and issue a replacement credential through the approved workflow.
Replacement phone	Confirm whether the credential transfers, requires re-enrollment, or has platform-specific rules. ButterflyMX documents that a new phone requires a new Wallet Pass.
Low battery	Plan a physical or PIN fallback. Apple says some supported Express Mode items can work for up to five hours after an iPhone needs charging, but not after the phone is powered off.
Internet outage	Separate local credential presentation from remote commands, permission updates, and cloud-managed functions. Verify behavior for the chosen system.
Building power outage	Review reader, controller, lock, backup-power, and life-safety behavior for each entry point with the relevant provider and property team.

Do not extend Apple power-reserve behavior to Android devices or to every access product. The five-hour statement applies only to some supported Express Mode items on iPhone, and Apple says it does not apply once the phone is powered off. A reliable property plan uses that limited feature as a convenience, not as the only continuity measure.

Wallet lifecycle rules can also shape support work. ButterflyMX states that its Wallet Passes are device- and platform-specific, and its documentation describes activation, re-adding, replacement, revocation, and logging considerations. Those rules should be checked again before deployment because wallet and platform policies can change.

 

Combine mobile access with cards and fobs

Yes, mobile credentials can coexist with cards and fobs when the readers, credential technologies, controller, wiring, and management platform support the combination. The key word is when. An inventory should come before a promise to reuse existing hardware or eliminate physical credentials.

1. Inventory every entry point, existing reader, controller, credential type, wiring condition, and user group.
2. Identify which mobile methods each location can support and where compatibility needs confirmation.
3. Run a limited pilot with representative residents and staff.
4. Keep PIN, fob, card, or staffed fallback routes during the pilot.
5. Train administrators and users on activation, replacement, loss, visitor access, and move-out steps.
6. Review failures and support requests before expanding the rollout.

Physical credentials remain part of many real-world deployments. HID reported in its 2026 vendor-run, global, cross-industry survey that 84% of surveyed end users retained physical credentials alongside mobile credentials. That figure is not multifamily-specific, but it reinforces the value of planning hybrid access instead of treating physical fallbacks as an afterthought. Read HID 2026 security and identity report findings with that scope in mind.

Do not treat all legacy cards and fobs as equivalent. Their security and compatibility vary by credential technology and reader design. A site audit should identify what is installed before a team compares it with mobile methods.

 

Resident guest delivery and staff workflows

A good access system supports the people who use it every day, not only the opening action at the door. Residents and staff need an onboarding path, activation instructions, permission changes, replacement support, a lost-phone response, and a clear move-out process.

Guests, couriers, and vendors need a different workflow. The property should decide who can issue their access, which entrances they may use, when access starts and ends, whether a pass can be reused, and who reviews exceptions. A personal resident credential should not automatically become the property workflow for a guest or delivery person.

ButterflyMX provides a concrete example of why lifecycle rules matter. Its Wallet Pass documentation says passes are enabled per tenant, are non-transferable, have device and platform limits, and are revoked when the tenant is deleted. Supported Visitor Pass and Delivery Pass workflows can help separate temporary access from a resident credential, but each planned device and entry point still needs validation.

Assign ownership before launch. Someone should own new-device requests, urgent temporary access, support failures, permission approvals, and confirmation that credentials are removed at move-out. Clear ownership is often as important as the reader technology.

 

Evaluate costs governance and fit

Mobile access cost is not one line item. It can include hardware, reader replacement, installation, wiring work, software, credential provisioning, integrations, training, support, and replacement workflows. A property should request a configuration-specific scope instead of relying on generic per-door or per-user estimates.

Inclusion should be part of the buying decision. Pew Research Center reported in its October 2026 fact sheet that 91% of U.S. adults own a smartphone, compared with 79% of adults age 65 and older and 80% of adults in households earning under $30,000. Smartphone ownership does not establish wallet or system compatibility, but it is a useful reason to preserve alternatives. See Pew Research Center data on mobile-device use in 2026 for the population context.

 

Questions to ask before purchase

• Which credential methods work at each required entry point?
• Can existing readers, controllers, wiring, cards, and fobs remain in use?
• What happens after a lost phone, a device replacement, a low battery, or a powered-off phone?
• Which functions depend on internet, local network service, building power, or backup power?
• What fallback will serve people without compatible smartphones?
• How are visitor, delivery, vendor, and staff credentials issued, limited, logged, and revoked?
• Who can administer access, and what are the retention and notice policies for access logs?
• Which hardware, software, integration, support, and training costs apply to this configuration?

Written answers are especially valuable for continuity questions. They make it easier to compare proposals that use the same broad terms, such as mobile access or offline access, but behave differently in practice.

 

Where ButterflyMX fits in a phased rollout

ButterflyMX can be one option for properties evaluating mobile app access, compatible Apple Wallet and Google Wallet resident keys, supported intercoms and readers, visitor and delivery workflows, and cloud-managed permissions and logs. Its video intercoms also let residents receive visitor calls and grant access through their smartphones, without relying on a traditional POTS telephone line.

The most useful question is not whether every property should use the same setup. It is whether the required doors, gates, garages, elevators, amenities, user groups, and fallback paths are supported in the proposed configuration. Use a property-specific review to validate each entry point, then pilot the workflows that matter most. Retain PIN, fob, card, or staffed alternatives until support and continuity needs are proven in the property environment.

For a practical next step, review your entry points, credentials, and fallback needs with a ButterflyMX access expert.

 

Frequently asked questions

Can residents tap like Apple Pay instead of opening an app?

Compatible NFC wallet keys can support a tap interaction at a supported reader. This differs from app-based BLE access. Apple Express Mode can allow some supported keys to work without waking or unlocking an iPhone, but availability depends on the property system, reader, phone, wallet, and provisioning rules.

 

Can one ButterflyMX Wallet Pass work on both iPhone and Android?

No. ButterflyMX documentation states that one Wallet Pass covers one iPhone plus an Apple Watch or one Android phone, not both platforms. A new phone requires a new pass, and current platform and billing rules should be confirmed before purchase.

 

Can one mobile credential open the front door gate elevator and amenities?

It can only do so when every entry point, reader, controller, permission, and credential method is supported and configured. A property should complete an entry-point audit rather than promise universal coverage from a single credential.

 

What should residents without compatible smartphones use?

Properties should plan alternatives such as supported PINs, cards, fobs, or staffed processes. These are inclusion and continuity measures, not exceptions to solve after launch.

 

Can residents share a mobile credential with another person?

Properties should use approved guest access instead of informal sharing of a personal resident credential. Apple documents sharing for supported multifamily keys, while ButterflyMX documents its Wallet Passes as non-transferable, so current platform and vendor rules must be checked.

 

Do mobile access logs create privacy concerns?

They can. Logs may support administration and investigations, but a property should define who can view them, how long they are kept, how residents are notified, and how records are used or deleted. Privacy obligations vary by property and jurisdiction.

 

Mobile access control is most useful when it is designed around the property, not around a phone feature. Match credential methods to each entry point and user group, test the lifecycle and outage scenarios, and maintain realistic fallbacks. ButterflyMX can support a phased approach where its compatible mobile, wallet, visitor, and access-management capabilities fit the property configuration. See how ButterflyMX could support a phased mobile access rollout at your property.

Get your free quote!

Fill in the form below, and we'll email you right back.

Want a free quote?

Fill in the form below, and we'll email you right back.