Volume 5

As some of you saw from posts and comments in the Secured Collective, I was in Austin this week for Acre's Partner Event. Overall, I saw continued touches supporting a strategy that bridges, figuratively and literally. More on that below.

First, to the event. I go to a lot of these. I get asked often if I like them… the truth is, I do. I really enjoy the intimacy of a 100-person event where you get a real chance to meet the room. Plus, I feel these types of events allow teams to really pay attention to the details, and it just feels different. Acre's marketing team ran a very tight event, and it stands out for things you don't see but, again, feel. The details were dialed in: the high-end, well-done barista all day, the boutique hotel selection on purpose, the custom agendas for each person, and the social programming tied to their heritage. That level of production matters because it signals to the 100+ VARs and all the strategic partners in attendance, like Zenitel, HID, and Allegion, that Acre is serious about the relationship, not just the transaction. The truth is, it's not hard to do this. All you need to do is let it happen and budget for it (and that does not mean the budget needs to be big btw. Just means it needs to be allocated properly).

The real takeaway that I saw was the shift in tone from last year to this one. Last year's event was a vision pitch: here is what we are going to do. People left with a feeling that something new was in the air and a sense of "ok, show me." Since then, the team has clearly been busy building. This year was an accountability check: they came "with receipts" (as one of the Acre team told me).

Personally, Acre brought me down for several reasons. I presented the State of Verticals report to that group, and I was thrilled to see the conversation around it reinforcing the same theme. I then moderated a panel discussion with their team that covered the Education, Health Care, and Tech verticals. Then I had the opportunity to interview Kumar Sokka, their CEO, in an AMA style format. We have posted the 20+ minute video in the Secured Collective as exclusive content for those of you in the app. I appreciate the partnership with Acre, which has given me the access and opportunity to bring it all to you here.

All in all, what I saw and heard is that partners are not asking Acre to dream bigger. They are asking Acre to prove the roadmap from 12 months ago turned into something they can sell today (here is what one of their VARs said after).

That leads us to the 5 announcements they rolled out…

The first was Acre Console, which brings access control, intrusion, visitor and identity management, and video into a unified UI. This is the platform move that every legacy manufacturer going after the Intelligence Era is making, and it puts Acre in the same conversation as the software-first players who built unified UX from day one rather than stitching it together after the fact. It's got a clean interface, and what it does, more than anything, is give a home to all the disparate systems that have made up Acre over the years. Each is in a different place regarding migration, but it is very clear where they are all heading (this answered the “who are they now and what are they doing?” question I got from the community).

Then came their Nexus Panel, which combines access and intrusion into a single hardware platform. You see this more often around the world, except in the US (at least for now), but it's clearly where the market is moving as we shift toward more integrated infrastructure rather than siloed solutions. Pairing this with Acre Console reinforced the story to partners about unification and showed it is not just a thin UI skin over separate backends. They brought it to the panel level too. They talked about this last year, and it was nice to see it live.

And speaking of talking about it last year and seeing it live today, they showcased real Bridge migrations that moved from a theoretical conversation to an implementation conversation, highlighting how end users migrated older platforms to the more up-to-date Acre Access Control. This detail really mattered to the VARs in the room when I asked, "What stood out to you?" because migration is where transitions in our industry often seem to die. As it was explained to me, "When a roadmap slides, it does not help me close more customers, as it creates some bad friction and bad blood. But this migration path gives me something I can sell to existing customers."

Then came a bit of a head nod (and a smile from me)…Acre Video. They wanted to make sure I was clear that Acre Video is not a strategy pivot, as they are doing this alongside continued support for third-party video partners like OpenEye (who was there). Acre Video is seen as an opportunity for Acre to reach into industry segments (SMB, for instance) that many legacy-thinking access control vendors have historically ignored. It also gives their integration partners more opportunities to turn on services under the same hood. But it was also clear that this is a bet that unified UI works better with unified capture, even if the camera hardware itself stays open. I've written about this often: access control is video, video is access control, and the quicker we get to that, the better.

And last, Acre Pro Services for VARs (note: not end users) was a recognition that the partner network desired support from Acre on increasingly complex, multi-discipline deployments. Professional services, especially as we continue to move toward looking more like the enterprise software industry, where security is a feature of a larger value proposition rather than security-only, support at the manufacturer level is table stakes for anyone selling a converged platform rather than a single-category product.

The clear takeaway is that the team is executing a vision and product strategy, and the integrators in the room were impressed mostly with the fact that they said they would, and they did.

Before I end, there was something that stood out to me as super interesting, and I wanted to touch on (and I am not sure it was explicitly understood, but it was definitely explicitly done): the use of the word "heritage" throughout the day.

It was very clear to me that Acre is threading a specific needle here between the old and new. They are purposely looking to honor and celebrate their legacy brands (they brought back the Open Options seafood boil and even asked some of the employees who were there back when that was a staple in the industry to speak. It became very emotional for some because it was very meaningful. It was a nice touch) and installed base that built the company's credibility, while, in the same breath, proving that the underlying platform is being rebuilt for where the industry is going. That is not easy. It's really hard. And it's even harder to do this type of messaging and deliver it convincingly. Most companies either lean too hard on heritage and read as stuck, or abandon it entirely and lose the trust of the base that got them here. I respect the way they are doing it and how it's being handled.
Acre Security is living the Platform Squeeze I talk about often, and we are watching it play out in real time. You can see it in their roadmap: hardware standardization, the move up the software stack, and the pressure for a unified UX are not abstract forces in a report. They are also doing it in their messaging: using the past on their toes versus their heels. The past is part of why they can, not the reason why they can't. That is the main tension they are navigating.

The test now is the one every partner in that room implicitly asked: will the Bridge migrations actually ship at the pace promised, and will Console and Nexus Panel show up as sellable products soon rather than as roadmap slides at next year's event? Acre bought itself credibility this week (this year). The main takeaway is simple: it now has to turn that credibility into delivery.

Thank you Acre for the opportunity to be there and see it first hand. 

AI has become part of many organizations, and access control requests increasingly come with the question: “Can we use AI to do it?”

Our work at evolutionID is mainly in physical identity and access management. So when we started working more seriously with AI, something felt uncomfortably familiar. AI can do what we want it to do, but it can also potentially reach, generate, or interact with things we do not want it to. For us, that looked like an access control problem.

Think about a normal access-controlled door. The system makes a specific decision:

“Does this identity have permission to perform this action, against this resource, right now?”

If the answer is no, access is denied. When AI enters the picture, the answer becomes less clear.

Language models are increasingly connected to databases, applications and tools. Then the important question becomes: “What is this system actually allowed to say or do?”

That is an authorization question.

Imagine securing a door with instructions. “You shall not pass!” It sounds ridiculous, but instructions are a common way to control a language model.

“Don't reveal this information.”

“Only use these tables.”

“Never perform this action.”

“Stay within this format.”

Prompting is useful, but from an access-control perspective, relying on instructions alone feels like putting a sign beside a restricted door saying:

AUTHORIZED PERSONNEL ONLY. PLEASE DO NOT ENTER.

It communicates policy, but it does not enforce it.

Another approach is to reject the output if it violates a rule. From a physical-security perspective, that resembles evaluating access after somebody has crossed the threshold.

Our instinct was to make the decision earlier. That led to a research project we called GRID, short for Grammar-Railed Decoding. The idea was to explore whether, instead of asking the model to avoid certain outputs and checking afterwards, we could restrict what the model can generate in the first place.

Take a simple database example. Imagine an AI assistant that should only read data. You could tell the model: “Do not delete anything.” With a stricter approach, the model should not be able to generate the DELETE command. It must not be able to reach those tokens, basically be “physically” unable to reach for that option.

Once we started thinking about the problem in those terms, the parallels with access control became quite clear, and several principles we already rely on in PIAM translate surprisingly well into AI systems.

1. Enforcement should happen before the action

A properly configured access system evaluates credentials before granting access. If AI can interact with business systems, unauthorized actions should be unavailable as early as possible.

2. Permissions should be specific

We don't give somebody access to an entire building because they need one laboratory. If a language model needs access to three database fields, why should it be able to access fifty? If a process only needs read access, why should destructive actions remain available?

3. Auditability matters

“The system shouldn't have allowed it” is a poor answer during an investigation. As AI moves into operational and access processes, a record needs to be kept of what the model was permitted to produce.

4. Boundaries should be explicit

No single security measure covers everything. A badge reader does not necessarily secure the window beside the door, and a PACS does not replace physical barriers, procedures or good system architecture.

AI controls need similar thinking. If a constraint cannot be enforced at the token level, it must be identified so another control can deal with it downstream.

We saw how important that was while testing with AI development frameworks. In one test case, constraints specified in code disappeared before they reached the model, but the application still ran. The output still parsed. Nothing obvious failed. The rule had simply never been enforced. Anyone who has worked in access control knows how worrying that can be.

Physical and digital security have converged for years. AI now adds another participant: something capable of reading information, selecting actions, invoking tools and affecting the systems around it.

That raises familiar PIAM questions. What may it access? What may it do? Under which conditions? Who defined that permission? Can we revoke it? Can we prove what it was allowed to do six months ago?

Our industry has spent decades working with these questions, and AI engineering is now wrestling with many of the same concepts, just named differently. That means the people who understand readers, controllers, credentials, identity lifecycles and authorization policies may have something useful to add to a conversation that currently sounds like it belongs entirely to software engineers.