Access Control Systems: Technology, Architecture & Intelligent Entry

The Fundamentals of Physical Access Control

What physical access control is

Physical access control is the practice of deciding who may pass through a controlled opening, at what times and under what conditions—and then enforcing and recording that decision. The opening might be a door, a turnstile, a vehicle gate, an elevator floor or a storage cage.

The word “physical” separates it from logical access control, which governs computer accounts and data. The two increasingly share identity data, but they protect different things.

An electronic access control system does three jobs that a key cannot:

• It decides per person and per moment. A key works for anyone holding it, at any hour. An electronic credential is assigned to a specific person, and the system applies that person’s permissions: only certain openings, only at certain times. The system recognizes the credential, though, not necessarily the person presenting it.
• It can be changed without touching the door. Revoking a lost credential is a database change, not a lock change.
• It keeps a record. Each attempt—successful or not—can be logged with the credential, its assigned holder, the opening, the time and the outcome.

Four distinct questions: identify, authenticate, authorize, enter

Everyday language blurs these together. Keeping them separate explains a great deal about how systems are designed and where they fail.

Anatomy of an Access Control System

An access control system is a set of devices, each with one job to do. Knowing which device is responsible for what is the fastest way to understand what you see at a door. It also tells you where to look when something goes wrong and who to call.

Credentials and readers: identifying the request

The credential is what a person carries, knows or is: a card, fob, phone, PIN or enrolled biometric. The reader at the opening captures it and passes it on. Readers come as card readers, keypads, mobile-credential readers, biometric terminals or combination units.

Operationally, the reader is the system’s face. Its lights, tones or display tell the user whether the request was accepted, and they are usually the first thing staff describe when reporting a problem. A reader that shows no response at all points to a different fault than one that shows a red light. In many systems the reader does not make the access decision; it collects the request and reports it.

Controllers: making and enforcing the decision

The controller (also called an access control panel or door controller) usually holds the rules for its doors and makes the grant-or-deny decision. It also watches door sensors and drives the lock and any local alarm.

A single controller may serve one door or many. In some systems the decision is made in a device at the door or inside the lock itself. What matters day to day is knowing which controller serves which doors, where it is mounted and how it is powered. A controller problem usually affects every door it serves, not just one.

Management software: where people administer the system

The access control management platform is where administrators add and remove people, assign credentials, set access levels and schedules, configure doors, and review events. It may run on a local server, as a hosted cloud service, or as a combination.

In many professional systems, the software sends rules to controllers in advance, so it does not approve each swipe in real time. In those designs, doors can keep working if the software becomes unreachable, but administrators lose the ability to make changes and see live events until it returns. Not every system works this way; some depend on a live connection for decisions or for particular features. Chapters 6 and 11 cover what that means in practice.

Electronic locking hardware: securing and releasing the opening

The locking device—an electric strike, electrified lockset, electrified exit device, magnetic lock or other electrically controlled mechanism—is what actually secures or releases the door when the controller signals it.

The lock is where electronic decisions meet the physical door and life-safety requirements. It is also where many day-to-day problems start, from doors that do not latch to locks that release slowly. Chapter 7 covers how these devices behave.

Door position and request-to-exit devices: reporting what the door did

A door position switch (DPS) reports whether the door is open or closed. Without it, the system knows only that it released the lock, not whether the door opened. Even with it, the system knows only that the door opened and closed. It does not know whether a person passed through, or how many. Confirming passage takes other means, such as video, people-counting sensors, turnstiles or vestibules.

A request-to-exit device (REX) tells the controller that someone is leaving from the secure side. It may be a motion sensor, a push button, or a switch built into a lever or exit device. Depending on the design, a REX signal may release the lock, suppress a false “forced door” alarm, or both.

Together, these inputs let the system tell a normal exit from a forced entry, and a closed door from one held open. When they are misaligned or missing, the result is false alarms, or real conditions that nobody is told about.

Power and communications: keeping everything running and connected

Readers, controllers and locks need low-voltage power, usually from dedicated power supplies or from Power over Ethernet (PoE) where the hardware supports it. Backup batteries are common. Their condition and capacity determine how long doors keep behaving normally during an outage.

Communications link readers to controllers, and controllers to the management platform over the facility network or an internet or cellular connection. When a link fails, the effect depends on which link it is and how the system is designed (Chapter 6).

Event records and monitoring: what the system can tell you afterward

Systems can generate an event for significant changes: a grant, a denial, a door forced or held open, a tamper signal, a power fault, a communication loss. Which events exist depends on the installed devices and on configuration. A door with no position switch, for example, cannot report forced or held conditions, and some events can be disabled or filtered. In many systems, events are stored on the controller, forwarded to the management platform, and often displayed in real time to operators. They may also trigger actions—an email alert, a camera bookmark, an output to another system.

The event log is the system’s memory, and it is only as useful as its setup. That depends on accurate clocks, consistent door names that staff recognize, and a retention period suited to how the organization investigates incidents.

At a glance: who does what

Access Permissions and System Logic

Credentials identify people. Permissions decide what those people may do. This logic layer is where an access control system expresses an organization’s rules.

Access levels and groups

Most systems do not assign doors to individuals one at a time. Instead, an access level (also called an access group, clearance or role) bundles a set of openings with a schedule. People receive one or more levels.

A mid-size distribution center might use levels such as:

• All Staff — Business Hours: main entrance and break room, weekdays 6:00 a.m.–6:00 p.m.
• Warehouse Floor — All Shifts: dock passage doors and warehouse entries, 24 hours on scheduled workdays.
• IT Room: network room only, any time, for three named people.
• Janitorial Vendor: main entrance and restrooms, weekdays 7:00 p.m.–11:00 p.m.

Role-based levels keep administration manageable. When someone changes roles, an administrator changes their level rather than editing door lists.

Schedules, time zones and holidays

A schedule (in some platforms called a time zone, a term unrelated to geographic time zones) defines when an access level or door behavior applies. Schedules can include day-of-week patterns, multiple intervals per day, and holiday tables that override normal days.

Doors also follow schedules independent of people. A lobby door may unlock automatically during business hours and require a credential otherwise. Some systems offer “first-person-in” logic: the door stays locked on its schedule until an authorized staff member badges in, so it is never left open on a snow day when nobody arrives.

Controllers keep their own clocks. Accurate time synchronization matters because schedules and event timestamps both depend on it.

Temporary credentials and revocation

Temporary access can be handled in several ways: credentials with start and end dates, visitor passes valid for a single day, or access levels that expire automatically. A roofing contractor might receive a credential valid only for the roof-access door, weekdays 7:00 a.m.–5:00 p.m., for the two weeks of the project.

Revocation removes a credential’s ability to open doors. In a networked system, a revocation made in the software is pushed to controllers, often within seconds to minutes, depending on the platform and network. In offline or standalone locks, the change may not take effect until the lock receives an update—a key difference explained in Chapter 6.

Anti-passback

Anti-passback rules stop one credential from being used to admit a second person or vehicle. Systems implement it in two broad ways, and they have different hardware requirements.

Area (zone) anti-passback tracks whether a credential is currently inside or outside a defined area. After a credential enters, it must be recorded leaving before it can enter again. Accurate tracking depends on the system knowing about exits, so exit paths in normal use generally need an exit-recording method, usually an exit reader and sometimes a vehicle detector in a lane. Where some exits go unrecorded (an emergency exit, for instance), in/out status drifts. Sites then compensate with soft mode, scheduled resets or procedures. Area rules are then enforced in one of two modes:

• Hard: a credential out of sequence is denied.
• Soft: the out-of-sequence use is granted but logged as a violation for review.

Timed anti-passback needs no exit reader. It blocks the same credential from being reused at the same reader, or group of readers, for a set number of minutes. It prevents passing a card back through a gate or fence, but it does not track whether the holder is inside.

Scope matters too. Local anti-passback is evaluated within one controller. Global anti-passback spans several controllers or sites and depends on those devices sharing status, through peer communication or a server. If that link is down, global rules may be suspended or reverted to local or soft behavior, depending on the product.

Exit readers for anti-passback are typically used to record exits, not to stop people from leaving. Requiring a credential to exit through a pedestrian door is a form of egress control that is restricted by building and life-safety codes, and is permitted only in specific circumstances. Vehicle lanes, turnstiles and parking exits are more common places for read-out because pedestrian egress is provided separately.

Anti-passback is most common in parking facilities, data centers and secured perimeters. It depends on disciplined use: under hard area rules, someone who leaves without badging, or tailgates out, will be denied on their next legitimate entry. Systems therefore need an administrative reset, and many reset all credentials to a neutral state on a schedule (for example, nightly).

Special door modes and rules

Systems can apply additional rules to specific openings:

• Two-person rule: two different authorized credentials must be presented within a set time.
• Escort required: a visitor credential works only after an authorized escort’s credential.
• Lockdown: an administrator or trigger places a group of doors in a state where normal credentials no longer release them, while maintaining required egress.
• Interlock (mantrap): in a vestibule with two doors, one cannot open until the other is closed.
• Occupancy limits: entry is denied once a count threshold is reached, where readers on both sides make counting possible.

Availability of each mode depends on the platform and the controller. Lockdown and interlock designs also require careful coordination with fire alarm and egress requirements.

Audit records and exception events

The audit trail answers two kinds of questions: who went where and when (transaction events), and who changed what in the system (administrative events). Both matter. An investigation into an after-hours entry may turn on whether someone added a permission the day before.

Exception events are the ones worth watching: access denied (with reason), door forced, door held open, tamper, duress codes where supported, anti-passback violations, and repeated invalid attempts. A useful system lets administrators route exceptions differently by door and time: a held door at a busy lobby at noon is noise; the same event at the server room at 2:00 a.m. is a signal.

Next · Chapter 06How Access Control Systems Communicate

How Access Control Systems Communicate

For a facility team, communications matter for three practical reasons. They determine which doors keep working when a link fails, what administrators can still do, and what the event history will show once things reconnect. This chapter explains enough of the architecture to answer those questions accurately.

The links that matter

Most systems depend on four kinds of connection:

• Reader to controller. Carries credential data from the door to the decision point. Older installations often use a simple one-way connection that is unencrypted and unsupervised: if it is cut or tapped, the system may not notice. Modern installations more often use a secure, two-way connection that is encrypted and reports faults. Which one a site has affects both security and how quickly a damaged reader is discovered.
• Controller to management platform. Carries rule updates down and events up, usually over the facility network or an internet or cellular connection.
• Platform to integrations. Links the access system to video, visitor management, HR or directory systems.
• Site to internet. Required for cloud-managed administration and for remote access to hosted services.

Where decisions are made, and why it matters day to day

The most important design question for continuity is which device holds the rules and makes the grant-or-deny decision.

• At the controller. A common commercial design. Rules are downloaded in advance, and the controller decides locally. A lost connection to the platform affects administration and event delivery more than door operation.
• At an edge device at the door. One device handles one or two doors. A failure stays local to those doors, but there are more devices to power and maintain.
• At the lock. Offline electronic locks hold their own credential list and audit trail. They keep working without a network, but changes reach them only when they are next updated.
• At a server or hosted service in real time. Less common for professional door control, though some systems use it for all decisions or for specific credentials, doors or functions. These designs depend most on the connection, so their offline behavior needs particular attention.

Architecture models compared

Door Hardware and Physical Operation

The controller decides. The door hardware carries out the decision. This is the point where access control intersects with mechanical engineering, building codes and life safety, and where many real-world problems originate.

Beyond the Door: Gates, Visitors, Campuses and Multiple Sites

The logic of an access event stays the same whether the opening is an office door or a truck gate. What changes is the physical equipment, the identity being verified, the environment, and the way permissions are organized.

Visitor entry

Visitors have no permanent credential, so the system needs another way to identify and authorize them. Three patterns are common:

• Intercom-mediated entry. An audio or video intercom at the entrance connects the visitor to staff, who verify identity and trigger a remote release. The access control system logs the release as an operator action rather than a credential grant.
• Visitor management. A visitor is pre-registered or checked in at a desk or kiosk and receives a temporary credential—a printed QR code, a day badge or a mobile pass—with limited doors and an automatic expiration.
• Escorted access. The visitor’s credential, if issued, works only alongside an escort’s credential.

Technically, the key distinction is who makes the decision. With an intercom, a person decides in real time. With a visitor credential, the decision is delegated to rules set at check-in.

Commercial vehicle gates

A vehicle gate replaces the electric lock with a gate operator: a motor that slides, swings or lifts a barrier. The access control system provides the authorization signal, but the operator controls the motion and its safety features.

Gate environments add requirements that doors do not have:

• Reader placement suited to a driver’s window, often on a pedestal or gooseneck, sometimes with a second reader at truck-cab height.
• Long-range identification using vehicle tags, long-range readers or license plate recognition (Chapter 10).
• Vehicle detection with ground loops or other sensors to know when a vehicle is present, when it has cleared, and to keep the gate from closing on it.
• Entrapment protection for people, typically photo-eyes and edge sensors required under the gate operator’s safety standard (UL 325 in the United States) and the gate construction standard (ASTM F2200).
• Weather and power considerations, since equipment is outdoors and operators draw significant power.

A gate grant only requests motion; the operator’s safety logic can override it. Exit is usually automatic through a vehicle detector rather than a credential, unless anti-passback or exit tracking is required.

Parking facilities

Parking adds counting and sequencing to vehicle access. Barrier-arm entries and exits commonly use anti-passback so one credential cannot admit two vehicles. Occupancy counts can track available spaces by level or by tenant allocation. Where parking supports paid or validated use, the access control system may integrate with a separate revenue or parking management system. In such cases, each system’s role in authorization should be clearly defined.

Multi-building campuses

A campus typically shares one cardholder database and access-level structure across many buildings, with controllers in each building connected over a campus network. The design questions are about scale and segmentation: how access levels are named so they remain understandable across dozens of buildings, how network outages between buildings affect each one (where controllers decide locally, doors generally keep working), and whether a campus-wide lockdown can be triggered and how quickly it reaches every controller.

Multi-tenant properties

In an office building or industrial park with several tenants, a single system often serves two kinds of administrators. The property manager controls shared spaces—lobbies, elevators, parking and amenity rooms. Each tenant may control their own suite doors and people.

Systems handle this through partitioning: tenant administrators see and manage only their own cardholders and doors, while shared-area permissions are managed by the landlord. Elevator control is a frequent integration point, limiting a credential to the floors its tenant occupies. The technical challenge is keeping tenant data separate while letting one credential work at both shared and tenant doors.

Multiple business locations

An organization with branches, stores or depots in several cities needs central visibility and consistent policy, and usually needs each site to keep operating when its internet link fails. In architectures built for this, controllers at each site make local decisions, and a central platform—on-premises or cloud—handles administration and reporting. Confirm which functions continue at a site that loses its connection.

Key differences from a single campus include internet-based communications rather than a private network, site-level administrators with limited rights, standardized door and access-level naming so reports are comparable, and planning for how quickly central changes (like revoking a departed employee) reach every site.

Next · Chapter 09Access Control and Video Intelligence

Access Control and Video Intelligence

Access control records what credential was used at which door and when. Video records what actually happened. Integrating the two connects identity data with visual evidence, but the two systems have different jobs and should not be confused.

How events reach video

Integration between an access control platform and a video management system (VMS) is usually built in one of these ways:

• Software integration: the two platforms exchange events and commands through a supported plug-in, API or software development kit. Access events appear in the VMS, often linked to the camera associated with that door.
• Unified platform: one software platform manages both access control and video natively.
• Hardware I/O: a controller output wired to a recorder or camera input signals an alarm condition. This is simple and dependable but carries little information—the video system knows that something happened, not who.

Every integration depends on supported versions and licensing on both sides. An integration that works with one software release may require updating after the next.

Verification and investigation

The most common benefit is event-linked video. When a door event occurs, the system bookmarks or displays video from the associated camera. An investigator searching for “all denied access events at the warehouse rear door last week” can review each with its video clip instead of scrubbing hours of footage.

Video also answers the questions access logs cannot:

• Was the person using the credential its assigned holder?
• Did more than one person pass on a single grant?
• What propped the door open?
• Did a forced-door alarm reflect an actual break-in or a faulty sensor?

Accurate time synchronization between systems is essential. A few seconds’ offset can link an event to the wrong portion of video.

A typical investigation follows a consistent path:

1. Start from the access event: filter by door, time window and outcome.
2. Open the linked video for each relevant event, allowing for any clock offset.
3. Confirm what the records alone cannot: who presented the credential, and how many people passed.
4. Check the administrative audit trail if a permission or schedule change may be involved.
5. Preserve the records and clips according to the organization’s retention and evidence procedures.

Alarms and response

Integrated systems can route access alarms—forced door, held door, tamper, repeated denials—to operators with live and recorded video. Rules can be conditional: a held-door event at the lobby during business hours might be logged silently, while the same event at a pharmacy storage room after hours triggers an alert with a video pop-up.

Where a remote monitoring center is involved, video verification can help an operator distinguish a genuine event from a false alarm before dispatching a response. Monitoring arrangements and dispatch requirements vary by provider and local ordinance.

Monitoring is not authorization

In a conventional integration, video watches the access decision; it does not make it. The controller grants or denies based on the credential and its rules. The camera records the result.

That changes only when video analytics are deliberately configured as an input to authorization—for example, a license plate read that triggers a gate, or a facial match used as a credential. That is a different architecture with different risks, covered in Chapter 10. Treating ordinary surveillance as if it were an authorization layer leads to false assumptions about what the system will prevent.

Integration limits

Integration capability depends on details that should be verified rather than assumed:

• Which events and commands the integration actually supports (some pass events one way only).
• Whether remote door commands from the VMS are permitted, and who can use them.
• How each system behaves if the integration link is down; events should still be recorded natively on each side.
• Licensing per door, per camera or per server.
• Update coordination, since a software update on either side can break a working integration.
• Cybersecurity: every integration opens a communication path that must be authenticated and limited.

Next · Chapter 10AI and Intelligent Access Control

AI and Intelligent Access Control

In access control, “AI” usually means machine-learning video analytics: software models trained to detect and classify objects, read text such as license plates, or compare faces. These analytics can now feed physical access workflows. Used carefully, they reduce friction and help people notice what matters. Used carelessly, they create new ways for the wrong person to get in.

This chapter follows these capabilities through real entry workflows. It covers how a match becomes an authorization, what happens on a false or missed match, how exceptions are handled, and what privacy, accessibility and fallback look like in daily operation. It also separates established practice from what is still emerging.

Detection, recognition and authorization are different jobs

Three terms are often blurred:

• Detection finds that something is present: a vehicle is in the lane, a person is at the door.
• Recognition identifies which specific thing it is: plate ABC-1234, this face matches enrolled person #418.
• Authorization decides whether that identity may enter here, now. In a sound design, authorization stays with the access control system’s rules, not with the camera.

Analytics are good at the first, increasingly capable at the second, and should hand the third to a rules engine that applies the same discipline as any other credential.

License plate recognition (LPR)

License plate recognition (also called automatic number plate recognition, or ANPR) uses a camera and software to read vehicle plates. It is among the most established forms of analytics-assisted access.

How an LPR gate workflow typically operates:

1. A vehicle enters a detection zone, triggered by the video analytic or by a ground loop.
2. A camera optimized for plates—often with infrared illumination and a fast shutter—captures images.
3. The recognition engine (on the camera, a local server or the VMS) locates the plate and converts it to text, often with a confidence score and, in some systems, the issuing state.
4. The plate string is compared against an authorized list. That list may live in the LPR software, or the plate may be passed to the access control system and treated as a credential.
5. If the plate is authorized for that gate and schedule, a supported integration sends a release command to the access controller or gate operator interface.
6. The gate operator opens, subject to its own safety logic, and both systems log the event with the plate image.

Design points that matter:

• A plate identifies a vehicle, not a driver. A borrowed or stolen car carries authorized plates. For higher-security gates, LPR is often paired with a second factor: a driver’s credential, an intercom verification, or a tag in the windshield.
• Reads are probabilistic. Dirty, bent, obstructed or unusual plates, specialty designs, glare and steep angles all reduce accuracy. Characters such as O/0 and B/8 can be confused. Systems need a defined fallback path for vehicles that fail to read (see “Fallback and alternative entry” below).
• Plates can be imitated. A printed copy of an authorized plate could fool a camera that reads only text. Some systems add checks such as vehicle make, color or a second credential; whether those checks are available depends on the product.
• Data retention. LPR systems capture every passing plate, not only authorized ones. Organizations should decide how long reads are kept, who can search them, and whether sharing with others is permitted. Some states regulate LPR data use, particularly by public agencies.

LPR in daily operation. Most of the work at an LPR gate happens in the exceptions. Typical situations look like this:

What Happens When Something Fails?

Every access control system will eventually lose power, lose a network link, or have a device fault. What matters is whether the facility team knows what the doors will do, what it can safely check, and when to call for help. The patterns below are typical; actual behavior depends on the specific hardware, configuration and site design, and should be documented and tested for each site.

Failures at a glance

Managing an Access Control System Over Time

An access control system is installed once and administered every day after that. Most real-world weaknesses come from operations, not technology: permissions that drift, credentials nobody revoked, software left unpatched, and logs no one reviews.

Credential administration

Good administration keeps the cardholder database accurate:

• Tie issuance and revocation to an authoritative source. HR onboarding and offboarding, tenant lease changes and contractor start and end dates should all trigger credential actions. Some platforms can synchronize with HR or directory systems automatically; others rely on manual steps.
• Handle lost credentials quickly. Disable on report, then reissue.
• Avoid shared and generic credentials. A “Maintenance” card used by six people produces an audit trail that identifies no one.
• Manage inventory. Track unassigned card stock, visitor badges and mobile credential licenses.

Policy changes and access reviews

Access levels tend to accumulate. People change roles and keep old permissions; temporary access becomes permanent. Periodic access reviews—in which department leads confirm who should have access to their areas—keep permissions aligned with need. Many organizations review sensitive areas quarterly and general access annually; the right interval depends on risk and turnover.

Changes to schedules, door modes and access levels should be documented, so an auditor can see why a door unlocks at 6:00 a.m. and who approved it.

Software and firmware updates

Management software, controllers, readers, locks and integrations all receive updates for features, bug fixes and security vulnerabilities. Cloud-managed platforms update their hosted software centrally, but on-site firmware may still require scheduled updates. On-premises systems also require server operating system and database patching.

Updates should be planned: check compatibility with integrations, back up configuration, schedule a maintenance window, and test critical doors afterward.

Cybersecurity maintenance

Access control devices are network devices and should be maintained like them:

• Change default passwords; use unique, strong administrator credentials and multi-factor authentication for software logins where supported.
• Limit administrator rights by role, and remove accounts for people who no longer need them.
• Keep devices on segmented networks with only necessary connections allowed.
• Encrypt communications between readers, controllers and software where supported.
• Monitor for vulnerability notices affecting installed components.
• Review administrative audit logs for unexpected changes.

Federal resources such as CISA’s guidance on securing connected devices, and established frameworks such as NIST’s, offer useful general principles.

Event retention

How long to keep event records is a policy decision, influenced by investigation needs, industry obligations, contracts, storage capacity and privacy considerations. Controllers hold limited events locally; the management platform keeps the long-term record. Cloud platforms may set default retention periods or charge for extended retention. Video linked to access events usually follows separate, often shorter, retention.

Whatever the period, it should be defined, applied consistently and supported by exports when records are needed for an investigation.

Hardware support and system lifecycle

Components age at different rates. Batteries need periodic replacement. Door hardware wears with traffic. Readers and controllers eventually reach end of support, when manufacturers stop providing firmware and security updates. Credential technology changes too, as organizations migrate from proximity cards to secure or mobile credentials.

Lifecycle management means tracking installed components, their firmware versions and support status, and planning gradual replacement rather than reacting to failures. Many organizations migrate in phases—often by using multi-technology readers that read both old and new credentials during the transition.

Next · Chapter 13Emerging Technologies and Future Directions

Emerging Technologies and Future Directions

Access control changes gradually, because installed doors, wiring and credentials last for years. The developments below are visible in the market today. Each is described by what is available now, what is developing, and what remains uncertain. “Available” means offered by some products, not all; support for any capability must be confirmed for the specific hardware, software and version involved.

Mobile identity and digital wallets

Interoperability and open standards

In practice: confirm that an integration is supported for the installed versions before relying on it, and retest integrations after software updates on either side.

Intelligent analytics

Advanced authentication

Evolving system architectures

Next · Chapter 14Technical Questions and Answers

Technical Questions and Answers

Next · Chapter 15Related Resources

Related Resources

Continue learning

• Planning a project? The Commercial Access Control Planning Guide walks through defining objectives, openings, users, budget and installation readiness.
• Working with Atlanta Access Controls: Learn about commercial access control services, including design, installation, upgrades and service, on the Commercial Access Control page.

Related topics

• Mobile credentials for commercial facilities
• Employee access control
• Warehouse access control
• Commercial gate entry systems
• Parking lot security with access control
• Upgrading an existing access control system
• Commercial video surveillance

Questions about how these systems would apply to your facility? Contact Atlanta Access Controls.