Rolling out a new access control system is one of those projects that looks straightforward from the outside. Install some readers, issue cards or mobile credentials, hook it into your doors, and you are done, right?
Anyone who has lived through a messy deployment knows it does not work that way. A poor implementation quietly bleeds money and time for years. People prop doors open, IT hates the software, security has to work around the system, and the business slowly loses confidence in anything labeled “security”.
I have walked into too many sites where expensive hardware was doing almost nothing useful. The good news: most of the pain points repeat from one organisation to the next. If you avoid the common mistakes, you can get a system that genuinely supports your operations instead of fighting them.
Below are ten traps I see most often, along with practical ways to sidestep them.
Mistake 1: Treating it as a hardware project instead of a security program
When executives sign a quote, what they usually see is a bill of materials for card readers, panels, locks, and licenses. That skews the conversation. People think they are buying “kit” rather than changing how the organisation manages identity, access rights, and auditability.
The result is a project framed around “what are we installing” instead of “what security and business outcomes do we want”.
A good access control system is one part of a broader security management system. The physical devices are only the visible layer. The deeper value is in:
- How identities flow from HR or IT into the system.
- How access rules match real business processes.
- How security and facilities respond when something goes wrong.
When you treat it as a hardware purchase, nobody owns those questions. IT assumes security will handle it. Security assumes facilities will handle it. Facilities assumes the integrator will handle it. The integrator just wants to get it built according to the drawings.
A better approach is to start with a short, sharp definition of purpose. For example:
“Within six months of go live, we should be able to grant or revoke access for any employee across all sites in under 10 minutes, have a full audit trail on who accessed which sensitive areas, and integrate access events into our incident response process.”
Once that is written down and agreed, every hardware and software decision has something to anchor to. You stop arguing about brands and start asking, “Will this design actually support that goal?”
Mistake 2: Forgetting that doors are used by people, not just readers
One of my early audits was at a manufacturing plant that had just spent a six figure sum on a brand new system. Every external door had badge readers, and the controllers were wired back neatly. On paper it looked perfect.
In reality, production staff were leaving loading bay doors on latch because they hated tapping in every time they moved between adjacent areas. The doors that “really mattered” to management had such strict rules that supervisors lent their badges to junior staff to get jobs done. The project had delivered physical control points that collided head on with how work actually happened.
The most reliable sign that a design will not work is when nobody from the shop floor, nursing station, call center, or any actual user group has been asked how they move, where they queue, or what slows them down.
During design, walk the building with the people who use it daily. Ask simple, practical questions:
- Where do you carry tools, boxes, or medical equipment that makes badging awkward?
- Where are the rush periods, and how long can people realistically wait at a door?
- Which doors must always fail safe for life safety reasons, and which can fail secure?
These conversations usually trigger small layout changes that make a huge difference, such as an extra reader on a side entrance used for smoking breaks, or a reconfigured turnstile at the main gate.
If people perceive the system as an obstacle, they will look for ways around it. If you design it around their reality, they are far more likely to respect it.
Mistake 3: Skipping proper credential strategy
No subject generates more eye rolls in project meetings than badges and credentials. It seems trivial, so it gets pushed to the end. That is how you end up with a shiny enterprise system tied to cheap, easily cloned cards or a messy mix of formats that nobody fully understands.
Credentials are your front line against tailgating, social engineering, and casual misuse. Weak choices here quietly undercut everything else.
There are three dimensions that need conscious decisions:
First, technology. Are you using legacy low frequency cards, modern encrypted credentials, mobile credentials, or a mixture? Modern systems strongly favor encrypted smartcards or mobile credentials, especially for any regulated or high risk environment. Yes, they cost more per unit, but the jump in protection from cloning is usually worth it.
Second, lifecycle. How are badges issued, replaced, suspended, and destroyed? If HR can terminate someone in the HR system but they remain active in the access control system for weeks, that gap is a real risk. Likewise, if nobody ever reclaims visitor badges, you will eventually have a bucket of valid credentials floating around town.
Third, uniqueness across the estate. I still come across multi site organisations where each site has its own badge numbering scheme. When they later want a unified security management system, they have to unpick years of inconsistent choices. Agree a global scheme early, even if you start with one building.
Spend a day getting credential strategy right at the beginning. It will save you months of retrofitting later.
Mistake 4: Designing in isolation from IT and cyber security
Modern access control is as much about data and networks as it is about locks. Controllers sit on your LAN, readers and panels often support IP, and the management software lives on servers or in the cloud. Yet I routinely see projects where IT is pulled in just before go live and told to “open these ports”.
That is how you end up with controllers dumped onto flat networks with default passwords, unpatched Windows servers running ancient management software, and no backup strategy.
There are two perspectives to bring into the room early.
IT operations cares about stability, performance, and support. They will ask where servers will live, how failover works, and what happens when a switch dies. Give them architecture diagrams, licensing details, and bandwidth estimates before you place any orders.
Cyber security cares about identity, access, and data exposure. They should review how admin accounts are managed, whether the system supports single sign on, how logs are stored, and whether the vendor’s cloud components meet your compliance requirements.
You want your access control system to behave like any other critical business system: change controlled, monitored, and backed up.
Done well, that collaboration unlocks positives such as integrating access logs with your central SIEM, or using your existing identity provider so administrators do not manage yet another set of passwords.
Mistake 5: Underestimating the power of a clear access model
One of the hardest parts of any implementation is translating “who should go where” into something the system can understand and maintain. Many projects jump straight into creating hundreds of small access groups like “3rd floor meeting rooms except north wing” because that is how the first few requests arrive.
Two years later nobody is quite sure what half the groups mean and new staff get either far too much access or too little, simply because it is quicker to copy an existing profile than to think it through.
A good access model starts with roles and locations, then connects them with simple, predictable rules. For Go here example, “All finance staff get access to floors 4 and 5 during office hours; finance managers also get out of hours access to the secure archive on floor 2”.
That statement can map cleanly into a role based structure. The important part is resisting the urge to solve one unique complaint by creating a custom group every time.
When I help teams build access models, we often sketch them on a whiteboard first, grouping doors into “areas of trust” rather than individual devices. Only once these areas make sense from a risk and workflow point of view do we break them into actual doors and time zones in the software.
The test of a healthy model: a new administrator should be able to explain, within a day of training, why a given person has the access they do. If they cannot, you are probably too deep into ad hoc territory.
Mistake 6: Ignoring visitors, contractors, and temporary staff
Most projects focus on employees, which is understandable. Yet many of the high risk access events in real life come from people who sit just outside that neat HR database: contractors, vendors, temps, and guests.
A common pattern looks like this. Employees are nicely integrated: HR triggers badge issuance, IT sets up accounts automatically, deprovisioning is relatively clean. Then contractors arrive, and reception or a local manager starts issuing “temporary” cards that never expire. Nobody truly owns those identities, so they linger far beyond the contract’s end.
Or, visitors. I have lost count of sites where guests sign a paper log, receive a generic “VISITOR” badge with no identity linked in the system, and then move independently within the facility. If something happens, you know only that “badge number 27” was in the data center between 14:00 and 15:00, which is hardly comforting.
Good practice is to fold these groups into your security management system with almost as much rigor as employees, but with different rules.
Contractors should have named records in the system, tied to a sponsoring manager or department, with explicit start and end dates. Some organisations require a fresh approval every 30 or 90 days for their continued access. It sounds bureaucratic until you realise how many former contractors otherwise quietly retain valid access.
Visitors need a simple but traceable process. That does not always mean fancy kiosks. Even a staffed front desk can record identity documents, capture who they are visiting, and issue uniquely numbered badges that are tracked and reconciled at the end of the day. The crucial step is linking the person to the credential in your logs.
Mistake 7: Leaving training and procedures as an afterthought
An access control system will not run itself just because it is installed. Someone has to interpret joiners, movers, and leavers. Someone has to review logs when there is an incident, update schedules for public holidays, and coordinate with facilities during maintenance.
Too many organisations rely on one “power user” who learned the system when it was installed and then informally trains others. That person goes on holiday or leaves, and nobody is quite sure how to add a new door or extract a report.
Equally important is how you explain changes to everyday users. If staff do not understand what is expected of them, they will invent their own rules. They might open doors for strangers out of politeness, share badges to speed things up, or ignore tailgating because “security never said anything”.
Formal, simple procedures go a long way. They do not need to be elaborate manuals. A handful of clear documents, shared and actually used, is more effective than a thousand pages nobody reads.
A basic set might cover:
- How to request new access or changes, and who approves.
- How to handle lost or stolen badges, including out of hours.
- What to do if a reader denies access or a door fails to open.
- The expected behavior at secure doors, such as challenging tailgaters.
From an administrator perspective, invest in proper vendor or integrator training for at least two people, and refresh it when you upgrade. It costs time, but it prevents subtle misconfigurations that compromise security, such as test accounts that never get disabled or emergency overrides that remain active.
Mistake 8: Treating integration as a “nice to have” instead of a core requirement
An access control system rarely lives alone. It touches HR, directory services, video surveillance, alarm systems, visitor management, sometimes even production systems like time and attendance.
If integration is left as “we will look at that later”, it usually never quite happens. The system then becomes another silo, and people resort to manual workarounds: emailing spreadsheets of badge numbers, double entering data, copy pasting reports.
Modern access platforms, especially when treated as part of a broader security management system, can exchange data cleanly with other tools. You can feed door events to video for instant playback, trigger alarms from access anomalies, or automatically add and remove users based on their status in the central identity system.
The key is to prioritise a small number of high value integrations, rather than dream up a huge list nobody has time to build.
Typical early wins include linking:
- HR or identity management with access, so staff automatically receive baseline access on their first day and lose it when they leave.
- Access and video, so a forced door alarm or denied access can bring up the relevant camera feed for operators.
- Access and IT service management, so hardware or software faults raise tickets automatically.
Discuss these needs when you evaluate vendors. Ask how they handle APIs, what is supported out of the box, and what has to be custom built. Integrations done later as an afterthought are more fragile and more expensive.
Mistake 9: Overlooking future growth and change
Buildings change, organisations merge or downsize, new compliance regimes arrive, and ways of working evolve. An access control system that fits your organisation perfectly this year may feel tight and brittle three years later if you did not allow for growth.
I once reviewed a corporate campus where the original installers had sized controllers for exactly the number of planned doors, with no spare capacity. When the business added a new wing, every panel in the chain had to be replaced. The direct cost was one issue, but the bigger headache was downtime and disruption.
The same pattern appears in software. A small on premise system that made sense for one building becomes very painful when you have five sites in different countries, each with their own policies and regulations. At that point you are trying to stretch a localised tool into a global security management system, which it was never designed to be.
Future proofing does not mean buying the biggest system you can find. It means asking sensible questions:
Is the platform capable of handling multiple sites under one umbrella, with local autonomy where needed?
Can we add different credential types later, such as mobile or biometrics, without ripping out everything?
How hard is it to add more doors, more readers, or integrate additional systems?
Also think about regulatory or customer demands that might arrive. A client with strict data protection requirements may expect detailed audit trails of who accessed which rooms. Certain standards demand specific authentication or logging features. If your platform cannot grow into those needs, you may be rebuilding sooner than you think.
Mistake 10: Installing and walking away
The easiest way to spot a neglected system is to look at its logs. If nobody has reviewed them in months, or if storage is full of years of unfiltered events, there is a strong chance the system is in “set and forget” mode.
Static access rights that nobody ever reviews slowly drift away from reality. People change roles, departments move floors, projects start and end, but access stays fixed. Over time, the gap between “who should have access” and “who actually has access” widens into something you could drive a truck through.
Healthy programmes treat access control as a living process, not a one off.
A practical rhythm looks something like this:
- Routine, light touch reviews of high risk areas, perhaps every quarter, where managers confirm who still needs access.
- Periodic testing of alarms and failover, including what happens in a power cut or network outage.
- Occasional drills that combine physical and cyber processes, such as simulating a lost master badge or suspected badge cloning incident.
The specific cadence varies by industry and risk appetite, but the principle is the same. Installations without ongoing care degrade. Installations with regular attention tend to improve over time as small tweaks accumulate.
A short planning checklist before you buy anything
If you have not yet signed contracts or started installation, working through a few focused questions can save a huge amount of rework. Use the following as a quick sense check.
- Have we written down our success criteria in plain language that business, IT, and security all agree on?
- Do we understand how staff, visitors, and contractors actually move through our spaces during a normal day?
- Has IT and cyber security reviewed the proposed architecture and vendor from their perspectives?
- Do we have a clear approach to credentials, identity lifecycle, and an access model that relies on roles rather than ad hoc groups?
- Have we identified one or two key integrations that must be in place for the system to be genuinely useful?
If any of these prompts trigger uncertainty or debate, that is a sign to pause and clarify before hardware starts appearing on site.
Choosing the right partners, not just the right products
The final mistake, which underpins many of the others, is treating vendor and integrator selection as a pure price and features exercise. The wrong partner can deliver a technically functional system that nobody likes, nobody understands, and nobody wants to maintain.
A good integrator does more than pull cable and mount readers. They ask awkward questions, push back on flawed designs, and know that a security management system only works when it fits both technology and culture.
Signals you are talking to the right kind of partner include:
- They insist on walking your site and speaking to different user groups before finalising a design.
- They bring up topics like HR integration, identity lifecycle, and long term administration without being prompted.
- They are candid about limitations and trade offs instead of claiming their preferred platform can do everything effortlessly.
- They talk about training, documentation, and aftercare as part of the proposal, not as an optional extra.
- They can point to similar organisations where they have maintained systems for several years, not just installed them.
Strong products with weak partners make for frustrating projects. Reasonable products with thoughtful partners often outperform them, simply because the design and implementation align tightly with your reality.
An access control system is one of the rare investments that quietly touches almost everyone, every day. When it is badly implemented, you feel it in small daily frictions, security gaps, and background grumbling. When it is done well, it fades into the fabric of the organisation. People move where they should, sensitive areas stay protected, and when something goes wrong, you have the data and processes to respond calmly.
Avoiding these common mistakes does not require heroics. It requires time upfront to ask better questions, involve the right people, and treat the project as the foundation of an ongoing security program rather than a one off construction task. That shift in mindset is where the real gains begin.