Volume 55

Volume 55 | April 17, 2026

This Week’s Featured Articles, Media, & Breaking News

✍🏻 Articles

Eric Joseph | Install Once, Risk Forever? Why Access Control Hardware Demands Lifecycle Management 
Access control hardware was never meant to run forever. In today’s connected environment, “still working” can quietly turn into “still vulnerable.”
Read below

Mitch Burcham | Trust Is the Interoperability Problem Nobody Wants to Talk About
Security systems can connect, but they still don’t trust each other. Until trust is verifiable, interoperability will keep falling short.
Read below

Brett Ennals | You Can't Scale a Security Business on People You Haven't Hired Yet: Why talent planning belongs in the boardroom
Growth doesn’t stall because of demand. It stalls because the right people aren’t in place when it matters most.
Read below

Jonathan Horvath | How to leverage open standards
Open standards are changing how systems are selected, implemented, and scaled. Most organizations aren’t thinking about it the right way yet.
Read below

Tony Dong | What Is The Best Path Forward For Allegion’s Capital Allocation?
With growth slowing, the real question becomes how capital gets deployed and which lever actually creates the most value.
🔒 Exclusive to Access Control Executive Brief subscribers. Excerpt below.

🎙 Secured Podcast

Episode 10 | Honeywell & LenelS2: The Future of Security's Biggest Brands
Honeywell and LenelS2 are at a turning point. The real question is what comes next.
Listen now.

🚨 Breaking News

Breaking: American Airlines deploys dormakaba electronic boarding gates at Dallas Fort Worth International Airport (DFW), becoming the first major U.S. network carrier to install the technology at scale at a major hub.

Scroll down to go deeper ↓

In the beginning, access control systems were treated like mechanical infrastructure. You installed them, they worked, and you didn’t think much about them again until something broke.  Then, in the early 2000’s, the realization that the access control software and the server running it needed to be upgraded regularly became universally accepted, but the access control hardware was often overlooked, as it could remain operational with only occasional firmware upgrades.

That approach used to work, but it doesn’t anymore.

What’s changed isn’t necessarily the access control hardware itself. Panels and readers are still incredibly reliable, the architecture is still similar, and the function it performs is still the same. The reader identifies the individual by presenting a credential, and the panel makes an access control decision to grant them entry. It’s not uncommon to see access control hardware running for 10, 15, or even more years without failure. That’s part of why the industry became comfortable with the idea that this part of the access control solution could run indefinitely.

But the larger environment in which that hardware is a part has fundamentally shifted. Today, access control is no longer a standalone system sitting quietly in the background. It’s connected. It’s integrated. It’s front and center to business continuity. And the access control hardware is now part of a broader network of devices that constantly communicate, update, and evolve. Whether organizations think of it this way or not, access control hardware is now part of the IoT ecosystem.

And once you view it through that lens, the “run it until it breaks” mindset starts to fall apart.

The issue isn’t whether the hardware still powers on. The question is whether it’s still doing what you need it to do in today’s environment and keeping your facility safe.  Is it a potential physical or cyber vulnerability?   In other words, is your access control hardware and equipment, whose purpose is to maintain security, now a potential attack vector for bad actors?

Older panels and readers weren’t designed for modern cybersecurity expectations. They weren’t built to support the levels or types of encryptions that organizations now require for all devices connecting to their network. And they certainly weren’t designed with future capabilities in mind, whether that’s end-to-end encryption, mobile credentials, or AI-driven functionality at the edge.

So, while a system may still be operational, it may already be vulnerable in ways that matter.

The risk here often does not affect the system's basic day-to-day functionality, which is why it is often overlooked. Organizations don’t feel the impact right away because employees can still access the buildings. But over time, it shows up in different ways. An IT scan identifies access-control hardware that is insecure.  A card is cloned and can be read by a reader, imitating a trusted cardholder.  Reader firmware upgrades need to be manually upgraded to each reader, rather than pushed from the system, to support mobile credentials.  What could have been a planned, controlled upgrade turns into a reactive, disruptive project.

And anything unplanned is always more expensive.  This is where the industry needs to shift its thinking.

Access control hardware should be managed with a defined lifecycle, just like any other technology hardware. Not because it’s failing, but because it’s evolving.

A practical benchmark is to think in terms of for access control hardware is a seven-year lifecycle; it may fluctuate a year or two in either direction, but seven years provides a strong baseline. That doesn’t mean replacing everything at once. It means having a strategy in place and planning ahead. Budgeting incrementally. Refreshing components in phases. Treating the system as something that needs to be maintained and modernized over time and in perpetuity.

This is not a foreign concept to enterprise organizations or large institutions.  This is how IT has operated for years. Security needs to follow the same model, and access control hardware can no longer be overlooked.

When organizations take this approach, they gain more than just predictability. They maintain a stronger cybersecurity posture. They stay compatible with new technologies. They’re able to take advantage of advancements as they happen, instead of being held back by aging infrastructure.

It also changes how conversations happen internally. Instead of asking, “Do we need to replace this yet?” the question becomes, “How are we planning for what’s next?”

One of the biggest barriers to this shift has always been financial. Traditional purchasing models and mindsets make it difficult to justify replacing something that technically still works. Large capital expenditures are easy to delay, especially when there isn’t an immediate failure forcing the issue.

That’s why alternative models are starting to gain traction.

Technology-as-a-Service (TaaS) and other technology evergreening approaches for access control hardware and software allow organizations to move away from large upfront investments and toward a more predictable operational model. Instead of buying a system and stretching it as long as possible, they can align costs with usage and lifecycle management expectations. Hardware refreshes become part of the plan, not an exception to it.

It’s a different way of thinking, but it aligns much more closely with how technology behaves today.

At the end of the day, access control systems are no longer static installations. They are living, evolving components of a connected environment. Treating them like mechanical fixtures with an unlimited lifespan no longer reflects reality.

The organizations that recognize this and plan accordingly will be in a much stronger position, both from a security and operational standpoint.

Because in today’s environment, it’s not enough for a system to keep running.

Because ‘still working’ isn’t the same as ‘still doing its job’.

The security industry has been talking about interoperability for years. Every conference panel, every vendor roadmap, every integration partner pitch circles the same promise: open systems, seamless data exchange, unified platforms. And yet most enterprises still run fragmented stacks where access control doesn't talk to video, video doesn't talk to intrusion, and none of it talks to IT without a pile of middleware and prayers.

We keep framing this as a technology problem. It's a trust problem.

The Real Blocker Isn't Protocol

When two systems can't interoperate, the surface-level explanation is always technical. Different APIs, incompatible data formats, proprietary lock-in. But underneath every integration failure is a more fundamental question nobody has answered cleanly: how does System A know that a request from System B is legitimate, authorized, and unaltered?

Today most security integrations solve this with static API keys, shared credentials, or broker middleware that both sides "trust" because a sales engineer set it up. There's no cryptographic proof that a credential request from your visitor management system was actually authorized by your access control policy engine. There's no verifiable chain from the person who badged in, to the system that authenticated them, to the video system that tagged the event. We have connections. We don't have trust.

Here's the thing. Identity is basically solved. The cryptographic toolbox is deep and mature. Every entity, whether it's a person, a device, a service, or an autonomous agent, can have a cryptographic identity that's verifiable by anyone, forgeable by no one, and doesn't depend on a central authority to validate. The problem isn't that we lack the tools. Our data layers live in silos, and you can't prove events across system boundaries without exposing the very data you're trying to protect.

Why Ownership Changes Everything

There's a concept that came out of the bitcoin world that most people missed because they were distracted by price charts. Bitcoin's real innovation was the merger of physicality and digitality. It made bits provably ownable. Not shared. Not held in trust by a platform. Owned, independently, provably.

That principle applies directly to security infrastructure. When a guard grants override access at 2 AM, who owns the proof of what happened?

Right now the answer is whatever vendor's database happened to log it. That proof lives on someone else's server, in someone else's format, subject to someone else's retention policy. You don't own your own audit trail. You rent it.

Now flip that. Every operation, every access event, every policy decision, every credential issuance produces a cryptographic proof that the originating entity owns. Not a log entry in a vendor database. A verifiable, portable, tamper-evident proof. When everyone owns their own proof and their own identity, trust flows directly between parties. No vendor in the middle brokering it. No middleware translating it. Peer to peer.

Interoperability becomes almost trivial when every component speaks the same identity-verified language because the trust model no longer depends on who built the system. You can swap backends, add subsystems, or replace vendors without rearchitecting trust. 

Why Security Is Still Stuck

The physical security industry hasn't adopted this model, and none of the reasons are good.

The dominant business model rewards lock-in. Vendors talk openness in keynotes and build walled gardens in code.

Buyers haven't demanded it forcefully enough. Most security directors evaluate systems on feature checklists, not on how the system proves the integrity of its own operations. If you can't cryptographically verify who authorized an action, which policy allowed it, and that the audit record hasn't been modified, you don't have security. You have a liability you haven't discovered yet.

And there's a conceptual gap. The industry still thinks of "trust" as a relationship between organizations. But institutional trust doesn't scale, especially not where we're heading.

AI agents are already being deployed to monitor feeds, triage alarms, and make preliminary access decisions. Every one of those agents is an entity making security-critical choices on your behalf. If that agent doesn't have its own cryptographic identity, its own audit trail, and its own verifiable proof of every action it took, you have no way to distinguish a legitimate automated decision from a compromised one. The same ownership model applies. The agent owns its identity. The agent produces proof. You verify it the same way you would verify a human operator.

What Actually Needs to Change

Vendors need to stop building identity into their product and start building their product onto identity. Integrators need to stop stitching systems together with middleware trust and start requiring cryptographic proof at every handoff. Buyers need to stop accepting "we log everything" as a security posture.

The shift is straightforward. Every entity gets a cryptographic identity it owns. Every operation produces a verifiable proof the originating entity holds. I can show you the proof. I own the proof. No vendor database. No platform dependency. Mine.

But here's the piece almost everyone misses. Vendor-neutral digital identity built on peer-to-peer electronic cash isn't just a better integration pattern. It's an inversion of the entire model.

Think about how every system works today. You log into applications. You authenticate to service providers. You hand your credentials to platforms and hope they handle them responsibly. The application is the authority and you are the supplicant.

When you own your cryptographic identity and you own every proof your operations generate, that relationship flips. Applications don't grant you access. They request access to your data, your credentials, your audit trail, and you grant or deny it. The platform authenticates to you.

The vendor logs into your trust boundary, not the other way around.

This isn't theoretical. The cryptography is deployed. The identity model works. The only question is whether the physical security industry adopts it before the next breach makes the decision for them.

The interoperability problem was never about protocols. It was about who owns the trust. Once that's you, everything else is engineering.

Most business owners in the physical security sector are good at winning work. The pipeline looks healthy. The order book is solid. And then growth stalls — not because of the market, not because of the competition, but because the right people aren't in the right seats when it matters most.

Talent planning is not recruitment. Recruitment is what you do when it's already too late. Talent planning is identifying the people capability your business needs twelve, eighteen, twenty-four months out and putting mechanisms in place to build or acquire it. Done well, it matters as much as your commercial pipeline or your capital allocation.

The Cost of Hiring in Crisis Mode

When a key technicians resigns mid-project or a competitor poaches your best installation team, the pressure to hire fast overrides the discipline to hire well. You pay over market rate, compromise on technical fit, and bring in someone who needs six months to become productive. In a sector where SLAs are contractual and a poorly commissioned system carries serious consequences; a bad hire is not just a financial cost it is a reputational one.

The companies that scale treat talent as a supply chain problem. They forecast demand, build pipelines, and never hire in crisis mode.

Talent Planning as a Growth Lever

The most common objection to talent planning is time. Owners and MDs are busy delivering projects. Strategic workforce planning feels like a luxury.

It isn't. It's a multiplier.

When you know what your headcount needs to look like in eighteen months, you make better decisions today which tenders to pursue, whether you can support a new vertical without overstretching your team, whether to grow organically or acquire. Every major bid decision in physical security has a people dimension. Talent planning makes it visible before it becomes a problem.

There is also a retention argument. Physical security is a relationship business clients renew based on the engineers who show up. Businesses that invest in their people's development keep their best performers longer. In a market this tight, that matters.

Understanding Your Skills Gap

A skills gap analysis is the diagnostic that makes talent planning actionable. In physical security, it typically sits across three dimensions.

The shift to IP, cloud, and AI analytics has outpaced workforce development in most businesses. Technicians competent on legacy infrastructure often lack the networking fundamentals or vendor certifications that modern integrated projects demand.

Most security businesses have strong individual contributors but a thin bench ready to step up. When a contracts manager leaves, the gap beneath them is often wider than expected.

As the sector moves towards managed services, consultative selling at IT director and facilities leadership level becomes critical. Most businesses have technical sales strength but lack people who can operate at that level and it limits the contracts they can pursue.

Map the capabilities your strategy requires, assess where your team sits today, and the distance is your gap. Those who do this find the gaps are rarely where they assumed and closing them proactively costs far less than managing the consequences of ignoring them.

The Businesses That Will Win

Physical security is at an inflection point. Demand for integrated, intelligent solutions is growing. The convergence of IT and physical security is creating new service opportunities and new capability requirements. The businesses best positioned to capture that growth are not the ones with the most advanced product portfolio.

They are the ones with the right people in place at the right time.

That happens because someone at the top decided to treat talent as a strategic asset not a cost, not a problem for later, but a long-term investment that underpins every contract won and every growth ambition realised.

If you are serious about growth, start there.

The physical security industry is quickly moving away from proprietary credentials There wasn’t much discussion at ISC West 2026 about existing or new credential standards that weren’t open. Many of the interesting demos featured open credential standards. It is apparent that future credentials will likely be based on open standards. The only question is the timing of deployments to actual customers.

Instead of going through all the open credential standards available, I will provide links below to some good articles that get into the details. The main purpose of this summary is to highlight purchase recommendations for customers and integrators. This guidance is not only for open standards for credentials, but they can also be applied to any open standard being considered. It can be overwhelming figuring out which open standard to deploy. The decision appears to become much more complex. No longer is selecting the correct security products enough to satisfy the requirements of an installation. Keep in mind that when selecting a product, there could be “baked in” standards. There could be standards that are developed internally that only work on products approved by the vendor. The supported standards are being selected for the customer by the vendor. With open standards, the customer can select the appropriate standard first. The purchasing approach needs to change from vendor to standards centric.

Selecting an open standard is like choosing a product. Requirements are determined and an evaluation is done to see if the open standard meets them. The specifications for the open standard should be readily available online. If it is difficult to obtain the specification for a standard, that would be a cause for concern. There are a few more items that should be considered when selecting an open standard. There needs to be an active working group committee that meets regularly to discuss improvements to the specifications of the standard. Ideally, it is easy to participate in these committee meetings. An open standard that has a publicly available reference implementation on GitHub will more likely become widely adopted. Open-source code greatly reduces the amount of time for a vendor to implement and support the open standard in their products.

Once the correct standard is determined, the next decision should be which products will best support the standard. There are a few criteria to determine if a product will properly support the open standard. Ideally, the products have been officially certified by governing body of the open standard. Certification indicates two important things. First is that the standard itself is mature and well supported. The other is the commitment of the vendor to supporting the standard with their products. For hardware-based products, it is important that their firmware can be easily upgraded in the field. A good open standard is constantly evolving, and it is desirable to support the latest versions.

We are still early in the adoption of these open credential standards, and some growing pains are inevitable. Organizations that build their purchasing decisions around open standards rather than vendor ecosystems will be better positioned for long-term flexibility and cost control. I hope this article helps in planning a path forward.

Aliro, PKOC, LEAF… What Do They All Mean?

Aliro NFID Brief

Allegion sits at an interesting point in its corporate life cycle. At roughly $12.3 billion in market capitalization, Allegion has just pushed past the mid-cap range into that awkward in-between zone. It’s no longer small enough to grow effortlessly, but not yet large enough to rely purely on scale and inertia.

This can be a sweet spot for disciplined growth, or it can quietly drift into stagnation. Add in the recent investment from Berkshire Hathaway, and it becomes even more interesting. When Berkshire shows up, the bar for capital allocation gets higher.

Personally, I think Allegion looks like what Warren Buffett would call a “wonderful company at a fair price.” You’re getting a wide-moat, oligopolistic business at about 16.3x forward earnings, with a 21% operating margin and a 36% return on equity.

Most of investing is about estimating future cash flows and discounting them back to today. That’s the quantitative side. The more qualitative, and often more important, question is what management does with those cash flows once they’re generated…… Continue reading by subscribing to the access control executive brief. Sign up here.

Podcast | Secured: Episode 10
In this episode of Secured, Lee takes a closer look at Honeywell and LenelS2 and the questions shaping their future. As signals shift and uncertainty grows, he breaks down what’s happening now, what the industry is still waiting to hear, and where things may be headed next. He also reflects on why clarity, leadership, and communication matter so much in moments like this, especially when two brands with this much weight are involved.

Listen now.