Base-Building Access

One credential for carpark, lift, lobby and suite.

Walk through a Perth office tower at 8:55am and watch what people carry: a building fob for the carpark, a card for the lift and speed gates, another card for their own suite door, and sometimes a PIN for the server room. It doesn't have to work that way. In most towers, tenancy access control can be connected to — or aligned with — the base-building system so that one card, or one pass in Apple Wallet or Google Wallet, opens everything a person is entitled to.

Get a Proposal Tell us about your project

Shared credential technology

The pragmatic baseline: your tenancy system is specified to read the same credential the building issues — modern encrypted smartcard formats, not legacy proximity — and the building card is enrolled in your system too. Two databases still exist, but staff carry one card. Works in almost any tower, because it needs cooperation on format, not deep integration.

Base-building integration

Your doors are brought onto, or interfaced with, the base-building platform. Enterprise platforms common in Australian towers, such as Gallagher and Inner Range, are built for multi-tenant partitioning: the building operates the head end, and your tenancy administers its own doors and users without seeing anyone else’s. One credential, one database, one revocation.

Mobile wallet credentials

Access passes in Apple Wallet and Google Wallet shift the token to the phone — provisioned and revoked remotely, nothing to lose. Where the building and the tenancy both support wallet-compatible readers, the "two tokens" problem collapses into one device even if the systems behind the doors stay separate.

Lift, lobby & carpark alignment

One credential is only one credential if it works for the whole journey: carpark gate, lobby speed gates, lift destination control scoped to your floors, then your suite doors. We establish what the building’s lift and access platforms can carry, and design the tenancy side to match.

The problem

Towers accumulate access systems the way they accumulate tenants.

The building runs one platform for the lobby, lifts and carpark. Each tenancy then installs its own system for suite doors — chosen by its own installer, on its own credential technology. Ten years in, the tower is running half a dozen incompatible credential formats, and every tenant's staff carry at least two tokens. The costs are mundane but constant: two registers to maintain, with every new starter needing credentials from the building manager and from your own system, and every departure needing revocation in both — in practice, one of the two always lags, usually the one that matters. Lost-card friction doubles: two replacement processes, two sets of temporary passes, two chances for a lost card to stay live.

Old technology lingers, too. Buildings and tenancies on legacy 125kHz proximity formats are carrying credentials that are trivially cloned. A tenancy can't fix the building's readers — but it shouldn't inherit their weaknesses on its own doors either. And for firms bringing clients through the lobby, fumbling between fobs is a small thing that reads as a big thing.

Building by building

What's possible depends on the base building.

This is the part no generic article can answer for you, because the answer lives in your building's riser. What we establish, tenancy by tenancy:

What platform the base building runs, and whether it offers tenancy partitions or a tenant integration pathway.
What credential technology the building readers accept — and whether it's a modern encrypted format worth aligning to, or a legacy format your tenancy should not adopt.
Whether lift destination control can carry tenancy permissions — so a visitor or staff credential is authorised to your floors only. See lift integration, plus lobby security and car park security for the building-side pieces.
Who administers what. The workable arrangements are always explicit: the building manages base-building doors, the tenant manages suite doors, and both know exactly where the line is.
What the building will actually agree to. Integration touches building infrastructure, so it runs through the building manager and the base-building contractor. This is where a tenant-side integrator earns its keep — we've sat on both sides of that table, and we deal with the building so you don't have to. Property and facilities managers coordinating this across multiple tenancies should see our property and facilities managers page.

The typical project, tenant-side

Audit. Identify the base-building platform, credential formats in play, and your tenancy system's capabilities. Often done as part of a tower audit.
Agree the model with the building: shared credential, partitioned integration, or wallet — and who administers which doors.
Align hardware. Tenancy readers upgraded where needed to the agreed credential technology — frequently the only hardware change required (see access control upgrades).
Enrol and migrate. Staff move to the single credential in batches; old tokens are revoked as each batch cuts over, not in one risky big bang.
Document and hand over. Credential register, admin roles and the building agreement in writing — so the arrangement survives staff turnover on both sides.

Wallet credentials typically carry per-credential licensing — a real cost to model, not a reason to avoid them. Our mobile credentials guide covers the mechanics, and our access control service covers the tenancy-side systems all of this builds on.

Common questions

Can our office access control use the same card as the building lifts and lobby? +

In most cases yes, provided your tenancy readers support the building’s credential technology and the building will share the format details needed to enrol its cards in your system. Where the formats are incompatible, aligning them is usually a reader-level upgrade on your doors rather than a system replacement.

Do we have to use the same brand of system as the base building? +

No. Matching the credential technology is enough for one-card convenience. Moving onto the building’s platform (or a partition of it) goes further — one database as well as one card — but it’s an option, not a requirement, and it depends on what the building operates and offers.

Can staff use their phone instead of a card for the whole journey — carpark, lift, suite? +

Where the building and tenancy readers both support wallet credentials, yes — an Apple Wallet or Google Wallet pass can serve the full journey. If only your tenancy supports it, staff can still use their phone at your doors while carrying the building card for the lobby; full phone-only access then depends on the building’s upgrade path.

Who controls who gets into our suite if we integrate with the base building? +

You do. Multi-tenant platforms partition administration: building management runs common areas, and your administrators run your doors and your user list. That boundary is agreed and documented before anything is connected — if a building can’t offer it, we’d generally recommend the shared-credential model instead.

What happens when someone leaves the company? +

With a single credential, one revocation covers the lot — and with wallet credentials it happens remotely, effective immediately. That’s the security argument for this whole exercise: today, most tenancies have a gap between building revocation and tenancy revocation, and departed staff live in that gap.