Taking Over a Kantech System: Integrator Checklist

Taking over an existing Kantech access control system requires more than getting administrator access and confirming that the doors unlock. Before accepting ongoing responsibility, security integrators should document the current hardware, EntraPass environment, operator accounts, credentials, access levels, schedules, network dependencies, integrations and known faults. The goal is to establish exactly what you are inheriting before your team starts changing it.

Key Takeaways

Treat an access control takeover as an audit first and a service account second.
Create a documented baseline before changing programming, credentials or hardware.
Review administrator accounts, service credentials and former users early in the takeover process.
Map network dependencies and third-party integrations before assuming an access control fault is actually an access control problem.
Use the takeover as an opportunity to determine whether the customer is better suited to a managed or hosted access control model.
Verify current Kantech compatibility and lifecycle information before recommending any migration or modernization work.

Why Is Taking Over an Existing Access Control Account Different From Installing a New System?

Winning an existing access control account can be a strong opportunity for a security integrator.

The customer relationship already exists. The doors are already equipped. Much of the infrastructure may still have years of usable life. There may also be an immediate opportunity for service revenue, upgrades and ongoing managed support.

The challenge is that you did not design the system.

With a new installation, your team controls the architecture, documentation, programming standards, credential structure and commissioning process.

With a takeover, you inherit decisions made by another company, potentially across many years.

That can include:

undocumented changes
inconsistent door naming
old operator accounts
temporary credentials that were never removed
custom schedules nobody remembers creating
third-party integrations
network configurations that have changed over time
aging components
incomplete backups
customer expectations based on how the previous dealer operated

The customer may also assume that everything was functioning perfectly before your company arrived.

That makes documentation critical.

If a door has been intermittently failing for six months, you want that recorded before a technician changes the controller configuration. If a former employee still has an active credential, you want to identify it before your team becomes responsible for routine administration.

A takeover should therefore begin with a simple principle:

Do not assume responsibility for an access control environment you have not yet documented.

The first job is not to improve the system.

The first job is to understand it.

What Information Should You Request Before Visiting the Site?

A good takeover starts before the technician opens the first enclosure.

Ask the customer for whatever documentation is available so your team can identify gaps before arriving on site.

Customer and Account Information

Start with the basics:

company name and account contacts
all sites included in the system
primary facilities or security contact
customer IT contact
current system administrator
backup administrator
people authorized to request access changes
emergency or after-hours contacts, if applicable

For multi-site systems, confirm whether administration is centralized or handled independently at each location.

A five-site customer with one facilities manager operates very differently from a five-site customer where each location manages its own employees.

Existing System Documentation

Request any available:

system diagrams
door schedules
panel schedules
as-built drawings
equipment lists
EntraPass information
registration or licence information
network documentation
IP addressing information
access level documentation
administrator procedures
previous service reports
records of unresolved issues
backup procedures

Do not assume the documentation is accurate simply because it exists.

A panel schedule created six years ago is a starting point, not proof of the system’s current configuration.

Previous Dealer Handover Information

When a cooperative handover is available, ask whether the customer can obtain:

current administrative access
current configuration documentation
known service issues
details about remote access
information about third-party integrations
recent system changes
relevant licence or registration records

Not every account comes with a clean handover.

Sometimes the new integrator is being hired because the previous relationship ended poorly. Sometimes the previous company no longer exists. Sometimes nobody at the customer’s organization knows where the original documentation went.

That does not necessarily prevent a takeover.

It simply means the discovery phase becomes more important and should be scoped accordingly.

What Should Be Included in a Kantech Takeover Audit?

A takeover audit should establish the technical and administrative condition of the environment before ongoing service begins.

A useful audit can be organized around ten areas.

Audit Area	What to Record	Common Warning Signs
EntraPass environment	Edition, version, registration and deployment	Unknown licence status, outdated documentation
Controllers	Model, location, communication and apparent condition	Unlabelled panels, aging or unidentified hardware
Doors and readers	Door name, reader, locking hardware and peripherals	Inconsistent naming, intermittent devices
Operators	Administrator and service accounts	Shared accounts, former staff
Cardholders	Active users, temporary credentials and exceptions	Old contractors, unused cards
Access levels	Doors, schedules and assigned groups	Excessive or unclear permissions
Network	Addressing, connectivity and IT ownership	Unknown firewall rules, undocumented dependencies
Integrations	Video, intrusion, elevators and third parties	Integration nobody currently supports
Backup/recovery	Current process and responsibility	No recent verified recovery process
Known faults	Existing defects and lifecycle concerns	Customer assumes old issues are now covered

Each area should be documented before major changes are made.

1. Identify the EntraPass Environment

Start with the software environment.

Record the information relevant to the deployment, including:

EntraPass edition
installed version
available registration or licence information
server or workstation arrangement where applicable
web or mobile components currently being used
number of sites and overall system structure
administrative access currently available

This information helps determine what your team is actually supporting and whether modernization should eventually be discussed.

Avoid making migration recommendations based solely on the age of the software.

Compatibility can depend on the current EntraPass environment, controller hardware, communications architecture, integrations and the proposed destination. Check current Kantech documentation and the requirements of the specific hosted environment before promising that an inherited system can be migrated without changes.

2. Inventory Every Controller

Document the controller environment site by site.

For every panel or controller, record:

model
physical location
doors associated with it
communication method
current network information where relevant
firmware information when needed for support or compatibility review
visible physical condition
enclosure condition
power supply
battery backup
obvious labelling or documentation problems

Photographs are valuable.

A good photograph of each enclosure can save significant time later when a remote technician or support partner needs to understand what is actually installed at the site.

Avoid relying only on what the software reports.

The database tells you what the system expects to exist. The site visit tells you what actually exists.

3. Map the Readers, Locks and Door Hardware

Access control is only one part of the opening.

A perfectly healthy controller cannot fix:

a failing electric strike
door alignment
a damaged reader
broken wiring
a failed power supply
a mechanical lock problem
a request-to-exit device that is not operating properly

Record the major field devices and identify obvious physical concerns.

This helps create an important service boundary from the beginning.

When a customer later says, “The access control isn’t working,” your team should be able to determine whether the problem belongs to:

credential administration
system programming
communications
electronics
locking hardware
the customer’s network
another integrated system

That distinction becomes even more important when you begin supporting the account remotely.

4. Audit Operator and Administrator Accounts

One of the most important parts of a takeover is identifying who can administer the system.

Review:

active operator accounts
administrator accounts
shared accounts
generic service accounts
previous integrator access
former employee accounts
unnecessary privileges
remote administrative access

Ask the customer who is supposed to have administrative authority today.

Do not assume every account in the system is still legitimate simply because it works.

A former employee, contractor or previous service provider may still have access because nobody was responsible for removing it.

Where practical, move toward individually assigned administrator accounts rather than shared credentials. Individual accounts make it easier to control permissions, remove access when someone leaves and understand who performed administrative actions.

5. Review Cardholders and Credentials

The cardholder database can accumulate years of history.

Look for:

terminated employees
expired contractors
temporary users
test credentials
unassigned cards or fobs
duplicate records
credentials with unexpectedly broad access
people whose access no longer matches their role

Do not automatically delete every credential that appears old or inactive.

Instead, produce an exception list and review it with the customer.

Only the customer can reliably tell you whether someone who has not used a card recently is a former employee, a seasonal worker, an executive who rarely visits the site or a contractor who still requires access.

This is also a useful opportunity to clarify the customer’s ongoing process.

Who tells the dealer when someone leaves?

Who approves new access?

How quickly are termination requests expected to be actioned?

The technical audit often exposes a process problem that is more important than the technology itself.

6. Review Access Levels, Schedules and Holidays

A cardholder record tells you who someone is.

The access-level structure tells you what they can actually do.

Review:

access levels
assigned doors
time schedules
holiday schedules
temporary exceptions
departmental groupings
unusual individual permissions

Look for inconsistency.

For example, one employee may have been individually granted access to a sensitive area two years ago rather than being placed into a properly defined access group. That exception may still be active even though the employee’s role has changed.

Complex access structures are not necessarily wrong.

Undocumented complexity is the problem.

The objective is to understand the logic well enough that your team can administer the account without creating unintended access.

7. Document the Network Architecture

Modern access control increasingly depends on the customer’s network.

That means an integrator taking over an account needs to understand where its responsibility ends and the customer’s IT responsibility begins.

Document relevant information such as:

controller connectivity
IP addressing
network ownership
switches or segments involved
internet dependency
firewall considerations
remote-access methods
IT support contact
known network changes
locations where connectivity has historically been unreliable

You do not need to become the customer’s IT department.

You do need enough information to recognize when an access control issue may actually be a network issue.

This becomes especially important with multi-site accounts.

If three controllers at the same branch go offline simultaneously, that is a very different troubleshooting scenario from one reader failing at one door.

8. Inventory Third-Party Integrations

Access control systems rarely remain isolated forever.

An inherited environment may interact with:

intrusion detection
video surveillance
intercom
elevators
human resources systems
directory or identity systems
visitor management
building automation
third-party applications

Document what is connected and, equally importantly, who supports each integration.

A previous dealer may have created a custom integration several years ago that nobody on the customer’s current team understands.

Before changing configurations or moving platforms, determine what depends on the current environment.

The last thing you want is to successfully modernize the access control system and then discover that an unrelated business process stopped working because nobody documented the connection.

9. Verify Backup and Recovery Arrangements

For an on-premise system, ask straightforward questions:

Is the environment being backed up?
Who is responsible for the backup?
When was the last successful backup?
Where is it stored?
Does anyone know how restoration would work?
Has the process ever been tested?

A file called backup is not the same thing as a verified recovery strategy.

If your company is going to support an on-premise environment long term, backup and recovery responsibilities should be explicitly defined.

This is one of the areas where hosted access control can change the service conversation.

Instead of inheriting the customer’s existing server and whatever maintenance history comes with it, the dealer can evaluate whether moving the account into a professionally managed hosted environment makes more sense.

10. Document Known Faults and Lifecycle Concerns

Finish the technical audit by separating current issues into categories.

For example:

Existing fault:
Rear employee entrance reader intermittently fails to recognize credentials.

Customer network issue:
Warehouse controller occasionally loses communication when the local network switch is rebooted.

Lifecycle concern:
Older component should be reviewed as part of future modernization planning.

Documentation gap:
No current drawing exists for the second-floor expansion.

Recommendation:
Standardize access-level naming before adding the next location.

This creates clarity.

Not every issue needs to be repaired immediately.

The important thing is that everyone agrees the issue existed at takeover and understands what happens next.

The Credential Problem Integrators Should Not Ignore

One of the easiest risks to inherit is also one of the least visible.

Old credentials.

A physical panel with a failing battery is easy to identify.

An active credential assigned to a contractor who finished a renovation two years ago may sit quietly in the database indefinitely.

Common examples include:

former employees
old contractors
temporary cards
commissioning credentials
test cards
service-provider credentials
duplicate employee records
cards that were replaced but never disabled
administrators whose roles changed years ago

The correct response is not to mass-delete anything that looks suspicious.

Build a review process.

Start by identifying records that appear inconsistent with the customer’s current employee and contractor list. Review exceptions with an authorized customer contact. Document what is revoked, retained or changed.

Then establish an ongoing offboarding process.

A well-configured access control system cannot protect a facility from an employee credential that nobody told the system administrator to remove.

That is why managed access control is as much about process as it is about software.

A recurring service relationship gives the dealer an opportunity to establish predictable workflows for additions, changes and removals rather than waiting for somebody to remember to call.

How Should You Document the Condition of an Inherited System?

At the end of the audit, create a written baseline.

It does not need to be a 40-page engineering report.

It needs to be clear enough that six months later both the customer and your service team can understand what existed when the account changed hands.

A useful takeover baseline can include:

System Summary

sites
number of managed openings
EntraPass environment
controller overview
major integrations

Current Administrative Structure

primary customer administrator
backup administrator
authorized requestors
dealer administrator accounts

Known Technical Issues

Separate confirmed issues from suspected issues.

Lifecycle Observations

Flag components or architecture that should be reviewed in future without unnecessarily telling the customer that everything old must be replaced.

Network Dependencies

Record what depends on customer IT and who should be contacted when connectivity is involved.

Photographs

Include panels, enclosures and unusual field conditions.

Open Recommendations

State what should happen next:

repair
further investigation
documentation
software review
credential cleanup
network coordination
modernization assessment

The baseline protects the service relationship because it removes ambiguity.

Your customer knows what your team found.

Your technicians know where they are starting.

Your sales team knows where legitimate improvement opportunities exist.

What Access Should Be Reviewed Immediately After a Takeover?

Once the current state is documented, administrative access should be one of the first areas reviewed with the customer.

Prioritize:

Former integrator accounts
Former employee administrator accounts
Generic or shared administrator credentials
Remote-access methods
Dealer service credentials
Accounts with excessive privileges
Temporary credentials with no clear owner
Credentials associated with former contractors

Do not simply change passwords without understanding what may depend on them.

A shared service account could be tied to an integration or process the customer still uses.

Review first, then change deliberately.

The objective is to reach a state where everyone with administrative access has a legitimate reason to have it and the customer understands how that access will be governed going forward.

This is increasingly important as physical security becomes more connected to IT environments.

Access control is not just a collection of locks anymore. It is a connected system with administrator accounts, network communication, data and remote management capabilities.

The takeover process should reflect that reality.

Should an Inherited Kantech System Stay On-Premise or Move to Managed Access Control?

Not every inherited system needs to be migrated.

The takeover audit should help you determine whether the existing architecture is still appropriate or whether the customer would benefit from a managed model.

Consider questions such as:

Question	If the Answer Is Yes
Does the customer have multiple locations?	Centralized management may be valuable
Are user and schedule changes frequent?	Ongoing administration may justify managed service
Does the customer want remote access to administration?	Hosted management may be worth assessing
Is the local server becoming a support burden?	Managed hosting may remove an operational headache
Does the dealer want more predictable recurring revenue?	Managed service can create an ongoing relationship
Is customer IT asking to reduce locally maintained infrastructure?	Hosted access control may better fit their IT strategy
Are backups, updates and server responsibilities unclear?	A managed architecture may simplify ownership

The purpose of this conversation is not to sell cloud hosting to every inherited customer.

It is to determine whether the current architecture still matches how the customer wants to operate.

For some accounts, continuing to support the existing on-premise environment may be the right choice.

For others, the takeover is the ideal moment to modernize.

If the existing hardware may be reusable, review our guide to moving to cloud-managed access control without automatically ripping and replacing existing infrastructure.

The important part is to verify current compatibility before making promises.

Controller support, EntraPass requirements, firmware, integrations and the proposed hosted environment should all be reviewed against current Kantech and My Managed Security requirements.

What Changes When the Customer Becomes a Managed Access Control Account?

A managed model changes more than where the software runs.

It changes the relationship between the customer and the security dealer.

Instead of being called primarily when something breaks or a project is required, the dealer can become part of the customer’s ongoing access control operation.

That may include services such as:

hosted access control
remote administration
credential and user support
schedule changes
reporting
remote troubleshooting
ongoing system review
managed service agreements
multi-site support

For the dealer, that creates the potential for predictable recurring monthly revenue alongside installation and field-service work.

For the customer, it creates a more clearly defined support relationship.

But there is an important strategic question for the integrator:

Do you want to provide the managed service, or do you also want to build and operate the infrastructure behind it?

Those are not the same thing.

Running your own hosted access control environment means taking responsibility for another operational layer. That can involve infrastructure, maintenance, security, backups, availability, technical support and ongoing investment.

The Managed Services Dealer model offers another path.

A dealer can focus on:

winning and retaining the customer
designing the solution
installing and servicing the field equipment
defining the managed service offering
providing the customer-facing support relationship
building recurring revenue

while partnering with an established provider for the hattrix hosting layer.

For dealers already taking over Kantech accounts, that can be an important distinction.

You may already have the technical capability to support the customer’s doors.

You may already have the service team.

You may already have the customer relationship.

You do not necessarily need to become a cloud infrastructure operator before you can start building a managed access control practice.

Turn the Takeover Audit Into a Repeatable Dealer Process

The strongest security integrators do not reinvent their takeover process on every account.

Build a standard procedure your sales and service teams can reuse.

Before the Site Visit

identify customer stakeholders
collect existing documentation
obtain available system information
confirm sites included in the takeover
clarify known problems

During the Audit

document the EntraPass environment
inventory controllers and doors
photograph panels
review operator accounts
review credentials
map schedules and access levels
document network dependencies
identify integrations
review backup arrangements
record existing faults

Before Making Major Changes

issue the baseline report
review exceptions with the customer
agree on immediate priorities
define support boundaries
confirm authorized requestors

After the Takeover

clean up obsolete administrative access
complete approved remediation
establish the support process
document customer responsibilities
determine whether managed hosting should be evaluated
schedule an account review

Now the takeover becomes a productized service rather than an unpredictable technical exercise.

That is particularly valuable for dealers growing through acquisitions, competitive account wins or multi-site customer expansion.

Frequently Asked Questions

What should I request before taking over a Kantech system?

Request any available EntraPass information, system drawings, controller and door schedules, licence or registration information, administrator details, network documentation, access-level information, recent service history and records of known issues. A complete handover is ideal, but missing documentation should be treated as additional discovery work rather than filled in with assumptions.

Can I support a Kantech system installed by another security dealer?

In many cases, yes, but the existing environment should be audited before ongoing support commitments are made. Confirm the current software, hardware, credentials, network dependencies, integrations and available documentation. Any compatibility, licensing or migration questions should be checked against current Kantech requirements for that specific environment.

Should administrator credentials be changed after an access control takeover?

Administrative access should be reviewed early in the takeover. Former dealer accounts, former employees, shared credentials and unnecessary privileges should be identified with the customer. Changes should then be made deliberately so you do not unexpectedly interrupt an integration or process that relies on an existing account.

How do I know whether older Kantech hardware can still be used?

Identify the exact controller and device models first, then check current Kantech support and compatibility information for the proposed system architecture. Do not assume hardware needs replacing solely because it is older, but do not promise continued compatibility or cloud migration until the specific environment has been reviewed.

Can an inherited Kantech system be moved to hattrix?

Many existing Kantech customers may be candidates for a managed hattrix deployment, but suitability depends on the actual EntraPass environment, controller hardware, communications, integrations and current platform requirements. The takeover audit is the right time to gather that information and determine what, if anything, would need to change.

Should an access control takeover audit be billable?

A takeover audit requires technician time, system review and documentation, so many integrators treat it as a defined professional service rather than absorbing the entire process into future service work. The right pricing model depends on your company, the system size and how much information is available before the audit begins.

What documentation should the customer receive after the takeover?

At minimum, give the customer a clear summary of the system being supported, known issues, open recommendations, relevant support contacts and the agreed administrative process. More detailed technical documentation can be maintained internally or shared according to the scope of your service agreement.

What if there is almost no documentation for the existing system?

Start by creating your own baseline. Inventory the system physically and administratively, document what can be confirmed and clearly label what remains unknown. Missing documentation increases the amount of discovery required, but it is far safer to rebuild an accurate record than to rely on assumptions inherited from the previous relationship.

Taking Over a Kantech Account? Consider What Comes Next

Winning the account is only the beginning.

A thorough takeover tells you what the customer has today. It also gives you the information needed to decide what the service relationship should look like tomorrow.

For some customers, that means continuing to support the existing environment.

For others, it may mean standardizing administration, improving remote support, reducing dependence on customer-maintained infrastructure and building a managed access control relationship.

My Managed Security works with security dealers that want to offer managed Kantech access control without having to build and maintain the entire hosting environment themselves.

If you are taking over an existing Kantech account, we can help your team review whether the customer is a fit for the Managed Services Dealer model and what would be involved in moving the account toward managed hattrix services.

Talk to My Managed Security About a Kantech Account

This asset should remain ungated and link prominently back to this article.

Taking Over an Existing Kantech EntraPass System: A Security Integrator’s Audit Checklist

Submit a Comment Cancel reply

Recent Posts

Recent Comments

You have Successfully Subscribed!