Digital Keys, Fobs and Intercom Access: Who Controls Entry to an Apartment Building?

Digital Keys, Fobs and Intercom Access: Who Controls Entry to an Apartment Building?

What this guide covers

• Why access control is now a governance issue handled by the owners corporation, not a facilities task delegated to a building manager.
• How to build an access map across every door, lift, garage, plant room and parcel area in a scheme.
• The encryption gap between legacy 125 kHz fobs and modern MIFARE DESFire credentials, and why a $20 cloning device on Aliexpress is the practical reason to care.
• What to ask before signing an intercom replacement project that may run between $800 and $3,500 per lot.
• How the Privacy Act 1988, the Australian Privacy Principles and state Surveillance Devices Acts apply to access logs.
• The administrator-leaves problem: what happens when the building manager, strata manager or contractor with admin rights moves on.

Anyone who's tried to figure out how many fobs a 30-lot building actually has in circulation knows the answer is almost always "more than the register says, and nobody's quite sure who has them." That's the real starting point for this guide.

The front door of a 1990s apartment building was controlled by a brass key cut at the local hardware store. The front door of a 2026 building might be controlled by a fob, a Bluetooth credential on a resident's phone, a QR code from a short-stay host, a contractor PIN, a number-plate camera, a courier-only delivery code, a lift-floor restriction list, and an intercom app administered by a third party in another country.

Convenience is real. So is the governance problem. Owners corporations are now custodians of credential systems that decide who enters the building, what data is collected about every entry, and what happens when any of those systems fail or get compromised.

Access control is now governance, not facilities

For most of the past three decades, building access was a facilities issue. The strata manager held a master key. The building manager handed out fobs. Lost-fob fees showed up on quarterly statements. There was no register, no audit trail, no real exposure for the owners corporation beyond replacing a lock cylinder.

Three things have changed that.

Credentials are now data. A modern intercom or access controller logs every event: who entered, which door, when. That log is personal information about identifiable residents. The owners corporation commissioned the system and pays for it, so it's the entity that has to answer questions about how that data is collected, stored, accessed and disposed of.

Credentials are now revocable in software, not in hardware. Fair enough as an upgrade, but only if the owners corporation knows how to revoke them. It's a downgrade if the only person who knows the admin password is a contractor whose contract ended two years ago.

The threat model has changed. Short-stay rentals, food delivery, parcel couriers, NDIS support workers, cleaners, dog walkers, real estate agents, tradies. Buildings aren't closed environments with a known resident list anymore. A scheme with 60 lots may have 200 to 300 active credentials in circulation in a typical month.

The old facilities answer ("the building manager handles fobs") doesn't address any of this. The committee needs a documented access policy, an access register, a privacy position, and a plan for what happens when the system or its administrator goes away.

The access map

Start with a written map of every controlled access point in the building, the credential system that operates it, and who administers each one.

The map exists to answer four questions. How many active credentials are in the system? Who or what is each one assigned to? Who can issue and revoke them? Where are the logs?

A building that can't answer those questions isn't controlling access. It's hoping access is under control.

Legacy fobs versus modern credentials

The single most overlooked problem in Australian apartment access control is that the fob in your hand is probably not secure. The pattern's consistent across older schemes.

125 kHz EM and HID Prox cards. The dominant tech installed in Australian apartment buildings between roughly 2000 and 2015. These cards transmit a fixed serial number when presented to a reader. No encryption, no authentication, no replay protection. A handheld cloner sold on Aliexpress for $15 to $30 will copy any of these cards in under three seconds. There are YouTube tutorials with millions of views demonstrating it. Locksmiths, key-cutters and even some shopping centre kiosks now offer fob duplication as a casual retail service.

If your building's fobs were installed before about 2018 and the system wasn't deliberately specified as MIFARE DESFire or similar, assume they're clonable. Treat the fob as a convenience credential, not a security credential.

MIFARE Classic. A 13.56 MHz card used in some mid-2010s upgrades. Cryptographically broken since 2008. Shouldn't be specified for new installations. If your building has Classic cards, plan a migration.

MIFARE DESFire EV2 / EV3. The current secure baseline for apartment access. AES encryption, mutual authentication between card and reader, rolling identifiers. Can't be cloned with consumer-grade gear. Specify EV2 or EV3 explicitly in any new system tender. The cost difference between a DESFire and a legacy 125 kHz fob at procurement is small, typically $5 to $25 per fob versus $2 to $8, but the security difference is the difference between a credential and a souvenir.

Mobile credentials (Bluetooth and NFC). Phone-based credentials issued through an app. Generally use AES-encrypted protocols and additional device-level authentication. Stronger than legacy fobs in most respects, but they introduce vendor lock-in and platform dependency, which we cover below.

The committee question isn't "are our fobs working?" It's "are our fobs cryptographically modern, and if not, when do we migrate?"

The replacement fob price quoted to residents tells you something about the system. Buildings billing $30 to $100 per replacement fob on a 125 kHz system are recovering cost from a $5 component. Buildings billing similar amounts on a DESFire system are closer to recovering actual cost. Either way, the recovery rate should be set in a council resolution and explained, not invented at the front desk.

Intercom replacement projects: what to ask before signing

An intercom replacement is one of the larger discretionary capital projects a committee will run. A full IP intercom and access system with mobile credentials and lift integration typically runs between $800 and $3,500 per lot, depending on building size, cabling condition and how many access points get integrated. A 60-lot building can therefore see a project anywhere between $50,000 and $200,000.

The Australian market has consolidated around a handful of vendors. Knowing which ones operate locally helps the committee read quotes accurately.

Established analog and IP audio/video intercom. Aiphone (Japanese, dominant in Australia for residential strata, IX and IXG IP series widely deployed), Comelit (Italian, Ultra and Mini series common in newer developments), BPT/CAME (Italian, Mtm series and IP variants), Fermax (Spanish), Honeywell (legacy commercial-grade in some larger schemes), 2N (Czech, IP intercom strong in mixed-use), and Australian distributors and integrators trading through Intercoms.com.au and similar.

Cloud-first IP intercom with mobile credentials. Akuvox (broad SmartPlus platform), BUTTERFLYMX (US-origin, expanding in Australia, native mobile-first), 2N MyApp (cloud overlay on 2N hardware).

Access control platforms layered on top of intercom hardware. SALTO KS (cloud) and SALTO Space (on-premise), Kone KEN/KSM (where lift integration is the primary requirement), OneSafe (Australian access platform used in some smaller schemes).

The hardware choice matters less than the ten questions the committee should ask before signing.

1. Where is the cardholder and event-log data stored? Australia, the United States, Europe, somewhere else?
2. Who is the controller of that data? The vendor, the strata manager, the building manager or the owners corporation?
3. Who has admin rights at handover, and how is that account transferred when the administrator changes?
4. Can the system be administered without going through the vendor for routine tasks (add user, revoke user, reset PIN)?
5. Can the owners corporation export the full credential list, event log and configuration in a usable format at any time?
6. What happens when the contract ends or the vendor is acquired? Does the hardware keep working without the cloud component?
7. What's the firmware update path, and who pays for it?
8. What's the offline behaviour? If the internet drops, does the front door still open for residents?
9. Can emergency services enter the building without the cloud system?
10. What's the SLA for support, including overnight and weekend lockouts, and what does it cost?

The cheapest quote often loses on questions 5, 6 and 7. The system that ships with a beautiful resident app and an unbreakable proprietary admin portal is the system that'll be most painful to leave in eight years.

The vendor lock-in trap

Cloud intercom systems have made building entry dramatically more convenient. They've also introduced a category of risk that didn't exist with brass keys.

A typical pattern. A developer specifies a cloud intercom system at construction. Handover passes the admin login to the strata manager or building manager. Five years later, the owners corporation decides to switch strata managers or move building management in-house. The previous manager controls the admin account. The vendor's support is contracted to that account, not to the owners corporation. The credential database, the event logs and the configuration aren't portable. The owners corporation discovers it doesn't own its own front door.

You'd think this would be rare. It isn't. The pattern has played out across multiple Australian schemes. The fix when it goes wrong is a rebuild: reissuing every fob, reprogramming every reader, often replacing the controller hardware because the firmware is licensed to the previous administrator's account.

The structural fix is contractual, not technical. Before signing any access or intercom project, the committee should obtain in writing:

• Confirmation that the owners corporation is the data controller and the account holder.
• A clause requiring full data export at any time, in a documented format, at no cost.
• A clause requiring the vendor to transfer admin to a successor administrator on the owners corporation's instruction without obstruction.
• A clause stating the hardware continues to function in offline or local mode if the cloud relationship ends.
• An offboarding clause specifying how data is returned and deleted at the end of the relationship.

The strata manager, the building manager and the vendor are all routes through which the owners corporation interacts with its access system. None of them owns the system. The owners corporation does.

Mobile credentials and BYO-phone access

Phone-based credentials are now standard in new installations. The committee position should be informed rather than reflexive.

The pricing model is different. Mobile credential platforms typically charge $3 to $8 per active user per month, on top of hardware. For a 60-lot building with 100 active credentials, that's between $3,600 and $9,600 per year in recurring software cost. A real line on the budget, not a one-off purchase.

The user-experience advantages are real. Provisioning is instant. Revocation is instant. Lost-credential cost approaches zero because there's no physical fob to replace. Audit logs are richer.

The risks worth weighing.

Platform dependency. A resident on an outdated phone, an obscure Android handset, or a phone with Bluetooth disabled may be effectively locked out. Every mobile-credential system needs a fob fallback for residents who can't or won't use the app.

Account portability. Credentials are typically tied to an email address. When tenants change, the registration needs to be cleanly transferred or revoked. The committee should set a rule about how this is handled, and not assume the strata manager or building manager has set one.

Background battery and Bluetooth dependency. Some platforms require Bluetooth on and the app running in the background. iOS background-process management can interfere with this. Test with a real resident phone before signing.

Privacy. Mobile credential apps may collect device identifiers, location data and usage patterns. Read what the app is collecting and decide whether residents are being asked to consent to it.

The reasonable position. Offer mobile credentials as an option for residents who want them. Retain DESFire fobs for residents who don't. Never make app installation a condition of building access.

Contractor access: the most common breach

The single most consistent finding when an access system is audited honestly is that contractor credentials proliferate beyond what the committee imagines.

It happens through informal accumulation. A plumber needs access for a renovation in Lot 14. The strata manager hands over a master fob "to use this week." The plumber subcontracts to a tiler who keeps the fob in a van for three months. The cleaner who replaces the previous cleaner gets the same fob. The fire inspector gets a copy. By year's end, the building has three or four "spare" master fobs that nobody tracks.

A real audit pattern from a Sydney scheme. 80-plus active fobs in the system, only 60 lots in the building. Of the additional credentials, around half were former tenants whose fobs were never deactivated. The other half were contractors with no documented authority and no return date.

The fix is procedural, not technical.

• Issue contractor credentials by contractor and by job, not as anonymous "master" fobs.
• Require return on completion of the work, with a small bond ($50 to $100) held to enforce it.
• Set an automatic expiry on every contractor credential at issue. Typically 24 hours for a once-off attendance, or the contracted job duration plus seven days, whichever is shorter. Modern systems support time-limited credentials natively.
• Audit active contractor credentials quarterly and revoke anything older than the last completed scope of work.
• Treat the regular cleaner, gardener, pool company, lift technician and fire-protection technician as named credentials, not master credentials.

A master fob exists only in the safe, with a written sign-out log, used by the building manager or strata manager when no other credential will serve.

Short-stay rentals and access churn

Short-stay accommodation creates access churn the underlying fob and intercom system was rarely designed for. A lot operating as a short-stay listing might host 40 to 60 different guests in a year, each accompanied by partners, friends, cleaners, linen-change services and key-handover agents.

The numbers are striking. Buildings with three or more active short-stay listings see, on operator estimates, 30 to 40 per cent of their access events from non-residents. The intercom log of a building with active short-stay listings looks substantially different from one without them.

The committee position depends on whether the by-laws permit short-stay use at all (covered separately). In any building where it does occur, the access rules should specify:

• Whether temporary codes or guest credentials are allowed and how they're issued.
• Whether physical fobs may be given to guests and how the loss-and-recovery process works.
• Whether cleaners, co-hosts and key-handover agents must be registered and at whose cost.
• Who is the responsible person at the lot. The owner remains liable even when day-to-day issuance is by an agent.
• That misuse of access by a short-stay guest is a by-law breach attributable to the lot owner.

Privacy and access logs: the Privacy Act and state surveillance laws

Access logs are personal information. An entry showing that fob 0042 entered the rear pedestrian door at 23:47 on a Saturday is, for someone with the resident roster, a record of an identifiable person at an identifiable place at an identifiable time.

Two layers of law apply.

The Privacy Act 1988 (Cth) and the Australian Privacy Principles. The Act applies to "APP entities". Owners corporations with annual turnover above the small-business threshold (currently $3 million) are APP entities by default. Below that threshold, an owners corporation generally isn't bound by the Act, with two important caveats. It becomes bound if it provides a health service, trades in personal information, or contracts with the Commonwealth in certain ways. And best practice in handling resident data has moved toward Privacy Act alignment regardless of mandatory application. The Office of the Australian Information Commissioner (OAIC) treats the APPs as the practical baseline for any organisation handling resident data at scale.

The APPs that bear most directly on access systems:

• APP 3 (collection of solicited personal information): collect only what's reasonably necessary for the function of operating the building. A door-by-door event log per credential is generally justifiable. Continuous video matched to credential events may not be.
• APP 5 (notification of collection): residents should know that access events are logged, what is logged, who can see it, and how long it's kept. A standard notice posted alongside the building's CCTV notice satisfies this.
• APP 11 (security of personal information): the data must be protected against loss, misuse and unauthorised access. That cuts directly against shared admin accounts and informally distributed master credentials.
• APP 12 (access to personal information): a resident has a right to ask what information is held about them. The committee needs a process to respond, not a panic about the request.

The OAIC has issued non-binding guidance for residential and strata schemes on CCTV and access systems. It's the closest national reference document and worth reading in full.

State and territory Surveillance Devices Acts. Where access logs intersect with CCTV or audio recording, state laws layer on top of the Privacy Act. The exact statute varies.

• NSW: Surveillance Devices Act 2007 governs use of optical and listening devices. Audio capture at intercom call-points without notice is the most common compliance issue.
• Victoria: Surveillance Devices Act 1999. Similar position; audio is the principal restriction.
• Queensland: Invasion of Privacy Act 1971 is narrower than the Victorian or NSW Acts and focuses on listening devices in private conversation. Queensland's general regime is less prescriptive but the intercom audio question still arises.
• Western Australia: Surveillance Devices Act 1998.
• South Australia: Surveillance Devices Act 2016.
• Tasmania: Listening Devices Act 1991.
• ACT: Listening Devices Act 1992 and the Crimes (Surveillance Devices) Act 2010.
• Northern Territory: Surveillance Devices Act 2007.

The practical committee question for any system that records audio at the intercom or video at access points: are residents and visitors notified, is the recording justified by a building purpose, is access to the recordings restricted, and is retention defined?

The combined position. Set a written retention period for access logs (90 days is a common baseline; longer if there's a documented incident-investigation reason). Restrict who can access the logs. Avoid bulk export of logs to email. Tie any release of logs to a documented committee or strata-manager request. Cross-reference the access policy with the CCTV policy so the two documents don't contradict each other.

Who administers the system (and what happens when they leave)

The administrator-leaves problem is the most consistent governance failure in apartment access. It takes one of three forms.

The strata manager who held the admin account. The owners corporation changes strata managers. The previous manager's email address is the registered admin on the cloud intercom. The new manager has no rights. The vendor will only act on the registered admin's instruction. The previous manager has moved on and is slow to respond.

The building manager who held the admin account. A live-in or contracted building manager is dismissed or resigns. Their personal email is the registered admin. They retain administrative access to the system after their contract ends. In a documented Australian case, a former building manager retained admin rights to a cloud intercom for several months after dismissal; the matter became contentious before access was rotated.

The contractor who set up the system. The integrator or installer was given the admin account at commissioning and never handed it over. Routine changes go through them at a per-call rate. The owners corporation is paying for access to its own building.

In each case, the same root cause: there's no documented owner of the admin account.

The fix. The admin account on every credential and intercom system should be held in a generic, role-based identity that the owners corporation owns. For example, a dedicated email address controlled by the secretary or chair of the committee, with credentials held in the owners corporation's records. The strata manager and building manager hold operational accounts under that admin, not the admin itself.

The handover checklist applies any time the strata manager, building manager or contractor changes, and any time the committee composition changes substantially. Rotate passwords, audit user accounts, revoke unknown accounts, document the transfer in committee minutes.

Lost-fob and offboarding procedures

Two procedures, both deceptively important.

Lost fob. The resident reports a lost or stolen fob. The credential is revoked in the system within the same business day. A replacement is issued at a published cost (typically $30 to $80 for a DESFire credential, less for legacy systems where security justifies less recovery). The event is recorded against the lot, not against an individual, so the next committee can see the history.

A revoked credential should actually be revoked. Some systems "deactivate" a credential by setting a flag that can be reversed by anyone with admin access. Confirm what revocation actually means in your system.

Tenant offboarding. A tenancy ends. The managing agent notifies the strata manager or building manager. All credentials issued to that tenancy (fobs, mobile credentials, garage remotes, parcel-room codes) are deactivated. New credentials are issued to the incoming tenant.

The most common failure mode is informal handover between tenants, where the outgoing tenant simply hands fobs to the incoming tenant without notification. Credentials remain in the previous name in the system, and the building no longer knows who's actually inside it. The fix is a contractual obligation on managing agents and lot owners to notify the owners corporation of every tenancy change and to facilitate credential rotation as a condition of new occupation.

Costs and capital works planning

A rough planning matrix for a typical Australian strata scheme.

Access systems should appear as a discrete line in the capital works plan, with a forecast for the next replacement and a recurring budget for fob and credential turnover. The system has a lifecycle. Treating it as an event that happens once and is finished is the reason buildings find themselves running 15-year-old controllers on unsupported firmware.

Common objections and extra checks

"The strata manager already controls this." Administration isn't ownership. The owners corporation should know which account controls the system, who can export data, who can revoke credentials, and what happens if the management agreement ends.

"Mobile keys are more convenient." They can be. They also create phone-dependence, accessibility issues, short-stay churn, privacy questions and vendor lock-in. A building should keep a non-phone access pathway for residents who can't or don't want to use mobile credentials.

Check emergency access before changing anything. Fire brigade entry, lift override, garage egress, power-failure behaviour and mechanical key backup should be confirmed before a new intercom, fob or mobile credential system goes live.

Audit master credentials separately. Contractor fobs are one problem. Master credentials are a larger one. The committee should know how many exist, who has them, whether they're logged, and whether any can open plant rooms, roofs, parcel rooms or amenities outside normal hours.

Committee checklist

1. Build a current access map covering every controlled door, gate, lift and amenity.
2. Build a current credential register: how many active credentials, assigned to which lots, contractors and visitors.
3. Audit credentials against the lot roster; revoke anything orphaned, unattributed or older than the last known holder.
4. Confirm the encryption standard of the existing fob technology and document the migration position.
5. Identify the admin account on every access and intercom system and confirm the owners corporation, not an individual, controls it.
6. Issue contractor credentials by named contractor with an expiry date; audit quarterly.
7. Set a written access policy covering issuance, revocation, lost fobs, tenancy change and contractor access.
8. Set a written privacy notice covering access logs, retention period and access rights, aligned with the building's CCTV notice.
9. Confirm the system's offline behaviour and the emergency-services access route.
10. Schedule the next intercom replacement in the capital works plan, with cost ranges and a vendor-selection process that includes data-portability and exit clauses.

A note on cross-cutting risks

Access systems don't sit in isolation. The same credential framework that lets a resident through the front door also lets a courier into the parcel room, a guest into the rooftop, a contractor into the plant room and a cleaner into a short-stay lot. Decisions in one area constrain decisions in others.

How UnitBuddy fits

Access governance is a record problem first and a hardware problem second. The building that controls its own front door is the one that knows, at any moment, how many credentials are active, who holds each one, who administers each system, and what data the system is collecting on residents.

Take the dismissed-building-manager scenario. The contract ends on a Friday. By Monday morning, the committee needs to know which cloud intercom accounts that person was the registered admin on, which fobs were issued to them personally, which contractor credentials they authorised, and which vendor support relationships are tied to their personal email. More often than not, that information lives in a former building manager's inbox, a strata manager's filing cabinet, and three vendor portals nobody has the login for. The kicker is that until it's reconstructed, that ex-manager retains live admin rights to the front door.

UnitBuddy is built to be the record that makes Monday morning a five-minute job instead of a six-week investigation. For access control specifically, that includes:

• The access map: every door, lift call, garage gate, parcel-room lock, plant-room key, intercom panel and digital lock in the building, with the credential type and the system that controls it.
• A credential register: every fob, mobile credential, master key and contractor PIN, tied to a lot, a person or a contractor, with the date issued, the date returned or revoked, and the reason.
• The admin-account record for each cloud system, covering vendor, account holder, contract terms, data-export entitlement and offboarding clauses, so the owners corporation, not the previous strata manager, owns its own front door.
• The intercom replacement and procurement history, with quotes, warranties, courier-network compatibility and the data-portability terms negotiated.
• The contractor offboarding workflow: when a contract ends, the audit filtered to that contractor's credentials runs in seconds, not days.
• The lost-fob and tenancy-change ledger: reported lost, replaced, charged, cancelled, visible per lot and per tenant cycle.
• The privacy and data-handling notice the building issues to residents, with the retention period for access logs, the access-request process under APP 12 and the breach-notification trigger.
• The state-specific surveillance and privacy compliance file, holding the applicable Surveillance Devices Act references and any consent forms used for camera-and-access integration.

UnitBuddy is built to support owners corporations working alongside their strata manager. The strata manager calls the meetings, advises on the law, runs the levies. UnitBuddy holds the operational layer (the credential register, the admin-account record, the contractor offboarding, the privacy notice) that gives the committee the institutional memory access governance actually needs. In practice, the component that fails in apartment access control is rarely the hardware. It's the absence of records. UnitBuddy is built to hold those records, so when a contractor moves on, a strata manager rotates, or a vendor gets acquired, the building still owns its own front door.

Further reading

• QLD: Keys, fobs, swipe cards, security access and issues — via LookUpStrata
• NSW: Locking common doors without owner consultation in NSW — via LookUpStrata

Last updated: 7 May 2026. UnitBuddy publishes general information for Australian strata owners and committees. It is not legal, privacy or security advice.