Access control · acre security · Access Control and Feenics
acre is not a platform. It is a portfolio.
Behind the name there are several access control platforms bought at different times, and Feenics is the cloud one. Which of them you are offered matters far more than the name of the group, and it is the first question to ask.
What acre is, and what Feenics is.
The first thing to understand about this brand is that it is not a product: it is a group that has been buying up products.
acre security was formed by buying access control firms. That means that under the same name there are several platforms with different histories, architectures and tools. When somebody says «we're going with acre» they have not said anything yet: you have to ask which of them, and in writing in the offer.
Feenics is the cloud line, and it is the one that makes the group interesting in this conversation. It solves a very specific problem: you want the access server off your hands but you do not want to be tied to one manufacturer's electronics. The other lines run on your own server and play where the classic enterprise platforms play.
It turns up in corporate offices spread over several sites, in education, in healthcare and, above all, in clients who already have a server-based platform and have decided to get out of it without throwing away what is in the cabinets.
How it's built, and why it matters.
Feenics is cloud on top of controllers from the Mercury family, from HID. That is not a detail: it is the difference between one cloud and another. The head is outside, the decision stays inside the building on an off-the-shelf panel, and the panel is nobody's captive.
The practical consequence is that this architecture can be undone. If in three years you change your mind, your supplier or your platform, the cabling, the readers and the panel stay. With a cloud that runs on its own hardware that does not happen, and it is exactly the decision you pay for late.
What has to be looked at closely is the other thing: when a platform joins a portfolio, it is worth asking what its roadmap is, which line gets development and what happens to the old versions. It is not bad faith, it is what happens with product portfolios; and it shows three years later, when it is time to move up a version and it turns out the line you were sold is no longer the one getting the resources.
Four questions from the data sheet.
- Which line exactly, with its product name in the offer. Everything else depends on that, including the tool it is configured with.
- Which Mercury controllers are already installed, with their model and their firmware. That is what decides whether the migration is a change of head or building work.
- How it joins up with the video and with the intruder detection: through an API or through an integration that already exists, and how far each one goes. It is tested on a mock-up before it is promised.
- Whose name the cloud tenant is in. This looks administrative and it is the knot many clients get caught in: if the integrator created it with their own account, changing integrator gets complicated.
The cloud, the line and the RGPD.
Of the four cloud platforms in this group, this is the one that best withstands an outage. And for a reason of architecture, not of marketing.
The door panel has its own database of people, permissions and schedules, and it is the same type of panel the server-based enterprise platforms use. So with the line down the installation is not reduced to the bare minimum: it goes on applying its logic, it stores the events and uploads them when the connection comes back.
What you lose is the same as with any cloud, and it has to be said: a change is not propagated while the line is down, you cannot open a door remotely and you cannot watch it live. If somebody is removed right in that window, their credential goes on opening until the panel finds out.
And the data. The service is hosted on public cloud infrastructure, so you have to ask in writing which region, the data processor agreement with its list of sub-processors and the mechanism covering transfers outside the European Union. Plus one question almost nobody asks and which is the one that hurts most: what format the data is handed over in if one day you want to leave.
Who it fits, and who it doesn't.
It fits one case especially: there is already an enterprise platform built on Mercury controllers, the server is ageing, nobody wants to maintain it and you want to keep the investment in the cabinets. There this architecture is the natural answer and there is hardly any building work.
It also fits sites spread around that need more logic than a simple cloud gives: zones, anti-passback, complicated schedules, administration delegated by site.
It does not fit if what you want is what pure cloud customers want: one single firm, one single telephone number and zero technical decisions. Here there are more parts and therefore more design work. And it does not fit if what is installed is not Mercury, because then the main advantage is lost and the comparison with the other clouds starts again from scratch.
What we do with it.
- The inventory of what is in the cabinets before we offer anything: model and firmware of every controller, condition of the reader cabling and which readers they are. Without that, a migration quotation is a bet.
- The design door by door: credential, behaviour when the power goes, exit reading, the camera that watches it and coordination with the fire detection.
- The installation and the replacement of whatever needs it: power and backup, readers on OSDP where it can be done, locks and door furniture, and the network the system goes out on.
- The commissioning: the zone and schedule structure from the design, loading people from the right source, integrations checked and a written test door by door with a certificate.
- The maintenance and the ownership: backup and batteries, firmware, checking the credential list against the staff list, and the tenant and the passwords in the client's name. That last one we ask for ourselves even when the client does not.
Who configures it once we leave.
The day to day, the client. The layer underneath, no — and here the boundary is sharper than with a simple cloud.
Adding and removing people, the schedules, the permissions by zone and the temporary credentials are handled by the client from the browser, with roles that separate managing people from configuring the system. That can be run by the security team or by the IT team, and when both exist it is best to split it and write down who does what.
What the client does not touch is what lives in the panel: adding a controller, changing a door's mode, touching interlocks or anti-passback, upgrading firmware, rebuilding the zone tree. Here that matters more because there really are two layers, the cloud one and the panel one, and a change made badly in the lower one can leave a door behaving differently from what the screen above says.
What is handed over so they can: training by role, the door map with its behaviour, the zone and schedule tree exactly as it ended up, the panel inventory with firmware, who holds each role and one sheet with the five likely problems. And the reminder that a system only one person knows how to run breaks when that person goes on holiday.
Coming from something else.
The good case has already been said: if what is installed is Mercury, the panel, the cabling and the readers stay, and what changes is the head. The firmware has to be checked and the configuration rebuilt, and that is work, but no walls are opened and no cards are reissued if the current ones read.
What does not travel is the history: it is exported and archived separately before the old system is switched off. Nor do the peculiarities configured by hand over years on the previous platform — those workarounds nobody documented and that somebody will miss. They are dug out one by one before migrating, by asking, because they are not in the manual.
And if what is installed is not Mercury, the migration is the usual one: containment, power and door furniture stay, readers and cards are checked, and the electronics are changed.
The other six in this group.
Three more live in the cloud, with architectures that are not this one. Three do not. And the recommendation depends on what is in the cabinets.
Get started
What is in your cabinets today?
With the model of the controllers installed, the number of doors and who is going to handle adding and removing people, we can tell you whether this architecture saves you the building work or whether what you have calls for something else. And if it calls for something else, we say so before we quote.