I once watched a very confident person try to badge into a building with a supermarket loyalty card. Three swipes before they checked. We have all been some version of that person: the card is on the kitchen bench, you are halfway to work, and you’re not turning around. You are ringing reception.
That small everyday failure is why the most common question in physical security right now is “can my people just use their phone?”
It is a good question. It is also the wrong first question.
The right first question is the one this whole series has been building toward: how do you modernize, with phones, browsers, and cloud, without locking yourself into something you regret in three years? Because the villain of this part is not any particular technology. It is unmanaged change: the system nobody can leave, the one-off connections nobody remembers approving, and the quiet decision to keep doing what you did in 2014 because it still mostly works.
This is the last part of the foundations. Let’s finish them properly.
Key takeaways
- Keep your security platform as the brain and treat every client, app and connection as a face on it
- Treat mobile credentials as identities, issued and revoked through your standard joiner, mover, leaver process
- Adopt cloud on your terms across three shapes: cloud-delivered clients, connected remote sites, and controlled APIs
- Keep the platform as your system of record so new methods like frictionless access and asset tracking simply plug in
One brain, many faces
Here is the organizing idea for everything in this post, and it is worth writing on a whiteboard before any vendor meeting.
Decide where the brain of your security platform lives. For most enterprise deployments that is still a server you control, on premises or in your data center. Then treat everything else, every client, app and connection, as a face on that brain. The faces can multiply. The brain should not.
Ten years ago, there was only one face: a heavy-weight client on a fixed workstation in a control room. That still exists and still matters. But a modern platform such as Gallagher Command Centre now offers three ways in, and each has a distinct job:
- The full client is the power tool. Deep configuration, live alarm monitoring, complex reporting. It belongs on trusted workstations, with strong controls on who uses it and from where. This is where your security operations people live.
- The browser client is for people who manage access, not alarms. Reception, admin teams and guard desks were never going to use the power tool and handing it to them anyway was always more risk than value. What they need is a clean way to manage cardholders, credentials and access groups from a browser, with the data staying on your own server behind a secure gateway.
- Mobile apps are for people walking the site. A guard acknowledging alarms on a patrol. An on-call manager opening a door at 11pm without driving in. Small, role-appropriate slices of capability, in a pocket.
The story is not “replace the workstation”. It is the right door for the right role. If a proposal in front of you does not fit the brain-and-faces model, the burden of proof sits with the proposal.
Mobile credentials done well
Now the phones question, answered properly.
A mobile credential is just another way of proving who you are at a door. The phone replaces the card, not the decision. Your access control platform is still the brain making the call.
The practical wins are real. Fewer plastic cards to print, post, replace and eventually find in a washing machine. People forget cards constantly, but they almost never forget their phones. And when someone leaves, you revoke the credential centrally instead of chasing a bit of plastic across town.
The part organizations skip is the governance, and it is the part that decides whether mobile access becomes an asset or a mess. A mobile credential is an identity. It should be issued and revoked through the same joiner, mover, leaver process as every other identity you manage, driven by your identity provider, not handed out as a favor at the front desk. Roll mobile out as a convenience project with nobody owning the lifecycle and six months later nobody can tell you who holds a live credential. That is the same lesson as Part 3, wearing a different outfit.
One more thing: offer mobile, do not force it. Some people will not put a work credential on a personal phone, and they are allowed to feel that way. Keep a clean fallback and you avoid a fight you do not need.
Cloud, on your terms
“Cloud” does a lot of unpaid overtime in security conversations, so let’s be specific. For physical security it shows up in three distinct shapes, and they are worth keeping separate in your head.
Shape one: cloud-delivered clients for an on-premises brain
The browser client above is delivered using cloud technology, but it talks back to your own server through a secure gateway. You get the convenience of working from any browser, and regular feature and security updates, without lifting the core platform out of the building or punching risky holes in your network. For many organizations this is the sensible first move, not a migration.
Shape two: cloud-connected remote sites
Remote sites are where the pain lives: pump stations, substations, depots, construction sites. The old answer was a one-off VPN and a controller hanging off the back of someone’s router. Every one of those is a snowflake nobody wants to support at 2am, and together they turn your network into a homemade VPN museum. The modern pattern (Gallagher’s version is called OneLink) has the remote controller connect out over 4G, 5G or local internet, brokered securely back to your central server. The same pattern at every site, clean separation from your core network, and a much better story when risk and audit come asking.
Shape three: controlled APIs for cloud applications
When a cloud service needs security data, a tenant portal asking for occupancy, an analytics tool consuming events, the answer is a managed API gateway, not direct exposure of your server.
Notice the theme across all three. Your platform stays the system of record for doors, events and access decisions, and everything else reads or reacts through a controlled interface. That is the whole philosophy in one line.
What actually comes next
Future-gazing, but the useful kind. Three trends are worth your attention, and none of them require chasing fashion.
Frictionless access
Cards are being joined by phones, watches and whatever people already carry. Expect more mobile day to day, more interest in moving through certain spaces with fewer taps and turnstiles, and more biometrics at high-value doors, usually paired with another credential rather than trusted alone. The CIO questions never change: how does it plug into your identity provider, where is the sensitive data stored, and what is the option for someone who opts out? Keep the platform as the decision engine and treat each new method as just another way to prove who someone is, and you can evolve without restarting the story.
Asset tracking and richer data
As tags and sensors get cheaper, organizations will want to track high-value equipment alongside people and combine that with access events. This is an integration and data governance job, not a magic feature. Decide the system of record for each data type, and be deliberate about how long you keep fine-grained movement data for people and assets alike.
Smarter maintenance and health
The unglamorous one, and my favorite. Better diagnostics and connectivity are shifting security hardware from “fix it when it breaks” to “see it coming.” Health reports flag unsupported devices, warranty reporting lets you plan replacements before support ends, and even lock cycle counts tell you a lock rated for a hundred thousand cycles has quietly passed eighty percent of its life. Boring habits, but for hardware. Boring has been the winning theme of this entire series.
Four questions that keep you out of corners
When a cloud or mobile proposal lands on your desk, four questions keep you out of trouble. They are really one idea repeated.
- Where does the brain live, and is everything else just a face on it?
- Does every way in, the full client, browser client, and mobile app, go through your identity provider with multi-factor authentication, or are we breeding local passwords in dark corners?
- Are we giving people capability by role, or handing everyone the power tool because it was easier?
- For anything remote, are we using our standard connectivity pattern, or about to invent another one-off VPN we will be apologizing for later?
If a proposal cannot answer these, that is not a no. It is a “let’s talk before you sign”.
Two actions this week
One for you. Pick one site and decide which access method each role should use: who needs the full client, who belongs in the browser client, who needs the mobile app, and what they should and should not be able to do from it. Write it down. You now have a client access policy, which is more than most organizations can say.
One to do together. With your security or facilities lead, pick one remote site, even a tiny one, and map how it should connect using your standard pattern rather than a network exception. Then update your architecture diagram so the brain, the faces and the connectors are visible in one picture.
Neither needs budget. Both compound.
Where the story goes next
That closes out the foundations. Six parts in: your building is full of small computers, their data tells useful stories, boring habits keep them safe, deliberate integration makes them part of your architecture, access data becomes safety and compliance, and now phones and cloud extend it all without surrendering control.
But here is the thing this series has been quietly circling. Getting one site right is not the hard part. The hard part is the whole estate.
Most organizations do not carry one tidy system. They carry a pile of them, bought site by site, project by project, vendor by vendor, with nobody holding the whole picture. There is a hidden cost in that, and it almost never appears as a line on anyone’s budget. I have started calling it the fragmentation tax.
That is where this series goes next. Less “how do I run one good system” and more “how does a technology leader bring a whole fragmented estate back under control without ripping everything out”. The standard. The stakeholders. The strategy. It is the point where physical security stops being a technology you manage and becomes a position you hold at the leadership table.
If these six parts were the foundations, the next six are the architecture. See you there.