Cloud access control does not eliminate security responsibility. It redistributes it. The customer remains responsible for decisions such as who should have access and its own internal policies. The security integrator is responsible for secure deployment and administration within its scope. Platform and hosting providers are responsible for the infrastructure and services defined in their agreements.

For security dealers, understanding those boundaries is becoming increasingly important as access control moves further into connected, remotely managed and cloud-hosted environments.

Key Takeaways

  • Cloud access control operates under a shared responsibility model. No single party controls every part of the environment.
  • Dealers should understand the difference between customer, integrator, hosting provider and manufacturer responsibilities.
  • Administrator accounts, credential changes, remote access and customer network dependencies should never be left undefined.
  • Moving an access control system to the cloud does not transfer all cybersecurity or privacy responsibility to the hosting provider.
  • Canadian data residency can be valuable, but data residency alone does not establish privacy or security compliance.
  • Security dealers should evaluate hosting partners based on governance, access controls, infrastructure, incident processes, recovery and support, not simply whether the solution is described as “cloud.”
  • A Managed Services Dealer model can allow integrators to offer cloud-managed access control while partnering for the infrastructure layer rather than operating it themselves.

What Does Shared Responsibility Mean in Cloud Access Control?

The idea of shared responsibility is well established in cloud computing.

When an organization uses a cloud service, responsibility for security is divided across the customer, cloud service provider and any other partners involved in managing identities, infrastructure or services. The Canadian Centre for Cyber Security specifically notes that cloud-based identity and access-management models can require coordination between multiple parties and recommends clearly defining account-management responsibilities.

Physical access control adds another layer of complexity because the cloud platform is connected to a physical environment.

A typical access control deployment can include:

  1. The door and locking hardware
  2. Readers and credentials
  3. Controllers and field devices
  4. The customer’s local network
  5. The access control application
  6. Administrator and operator accounts
  7. Hosted infrastructure
  8. Employee and cardholder information
  9. Integrations with other systems
  10. The customer’s internal access policies

No single company necessarily controls all ten.

A security dealer might install and configure the access control equipment but have no administrative control over the customer’s switches or firewall.

The customer might decide who should have access but rely on the dealer to configure those permissions.

A hosting provider may secure and maintain the hosted environment without deciding whether an employee should be allowed into the warehouse after 10:00 p.m.

The manufacturer develops and supports the underlying products but does not administer every customer’s employee list.

That is shared responsibility.

The important question is not:

Who is responsible for security?

The better question is:

Who is responsible for each part of security?

For a managed access control dealer, being able to answer that question clearly can prevent technical problems, reduce support confusion and strengthen conversations with customer IT teams.

Why Should Security Dealers Care About Cloud Cybersecurity?

Physical security systems are increasingly connected to the same networks, identities and business processes that IT teams are already responsible for protecting.

Kantech currently positions EntraPass as a connected access control platform capable of managing users, doors and multiple sites, with remote web and mobile management and integrations with other security systems.

That connectivity creates useful capabilities.

It also means dealers need to think beyond:

“Is the reader wired correctly?”

Questions from customers may now include:

  • Where is our information hosted?
  • Who can access the hosted environment?
  • How are administrator accounts secured?
  • Who applies security updates?
  • What happens if someone leaves our company?
  • What happens if someone leaves your company?
  • How are backups handled?
  • Who responds to a security incident?
  • Does our IT department need to manage anything?
  • What happens to our information if we change providers?
  • Where does your responsibility end and ours begin?

These are not unusual IT objections that need to be “overcome.”

They are reasonable questions about a connected security system.

A dealer that can answer them confidently is in a stronger position than one that treats cybersecurity as somebody else’s problem.

What Information Does an Access Control System Need to Protect?

Access control systems can contain information that is valuable from both a security and privacy perspective.

Depending on the system and configuration, that may include:

  • cardholder names
  • employee identifiers
  • credentials
  • photographs
  • access permissions
  • department or organizational information
  • door schedules
  • access events
  • entry and exit histories
  • administrator accounts
  • system logs
  • visitor information
  • network and device information

Some deployments may contain relatively limited information.

Others may contain extensive records about employees, visitors, physical locations and security events.

From a Canadian privacy perspective, organizations should not assume that outsourcing information to a cloud service transfers accountability for that information to the service provider.

The Office of the Privacy Commissioner of Canada states that when personal information is transferred to a cloud provider, the provider may have custody of the information, but the organization using the service still needs to maintain appropriate control and protection over the information it has outsourced.

For dealers, this does not mean providing legal advice to customers.

It means recognizing that access control data can be part of a customer’s broader privacy and information-governance responsibilities.

That is especially relevant when selling into organizations with formal IT, procurement, privacy or compliance requirements.

Who Is Responsible for What in Cloud Access Control?

There is no universal responsibility matrix that applies to every deployment.

Responsibilities depend on:

  • the service model
  • customer agreement
  • platform configuration
  • who administers the system
  • network architecture
  • integrations
  • support arrangements

However, a useful starting point is to divide the environment across four parties:

The customer
The security dealer or integrator
The hosting or managed service provider
The manufacturer or platform developer

The following is an example framework.

ResponsibilityCustomerSecurity DealerHosting / MSPManufacturer
Decide who should have physical accessPrimaryAdvise / configureNoNo
Notify when employees leavePrimaryProcess if contractedNoNo
Configure access levelsApprovePrimary or sharedSupport platformProvide functionality
Secure customer LANPrimary / customer ITCoordinateNoNo
Secure hosted infrastructureNoUnderstand scopePrimaryNo
Manage dealer administrator accountsSharedPrimaryShared where applicablePlatform controls
Product security updatesCoordinateApply / coordinatePlatform dependentDevelop / publish
Door hardware installationNoPrimaryNoProduct support
Hosted backup and recoveryNoUnderstand servicePrimary where includedPlatform capability
Respond to customer support issueSharedPrimaryEscalationProduct escalation
Remove terminated cardholdersInitiatePerform if contractedNoNo
Decide customer privacy policyPrimaryNoNoNo
Secure customer administrator devicePrimaryAdviseNoNo
Maintain product cybersecurity programmeNoNoNoPrimary

This is an example responsibility model, not a contractual standard. Actual responsibilities should be defined according to the deployment and service agreement.

The value of the table is not deciding that every box must always look the same.

The value is forcing the dealer to ask who owns each responsibility before a problem occurs.

What Is the Customer Responsible For?

Cloud-managed access control can reduce the amount of infrastructure a customer maintains, but it does not remove the customer’s role.

Several important decisions still belong with the organization being protected.

Deciding Who Should Have Access

The customer ultimately knows:

  • who works for the organization
  • which departments people belong to
  • which areas are sensitive
  • what schedules employees work
  • when contractors should have access
  • when someone has left the organization

A security integrator can recommend a sensible access-level structure.

The dealer should not independently decide that an employee belongs in a restricted area unless the service model specifically gives the dealer an approved process for implementing those decisions.

Maintaining an Employee Offboarding Process

One of the most important access control security controls happens outside the access control platform.

Someone must tell the system administrator when an employee leaves.

If an employee is terminated on Friday but the dealer is not notified until the following Wednesday, the technology cannot correct the process gap on its own.

Customers should define:

  • who initiates access removal
  • how requests are submitted
  • when termination access should end
  • who can approve exceptions

For larger customers, identity integrations can help automate parts of this process. Kantech currently offers Microsoft Active Directory integration designed to synchronize users and roles between Active Directory and EntraPass, including changes when users are added, updated or removed.

But even automation depends on good underlying identity governance.

Securing the Customer Network

Where controllers or other devices depend on the customer’s network, responsibility for that network usually remains with the customer or its IT provider unless the dealer has specifically contracted to manage it.

That may include:

  • switches
  • internet connectivity
  • firewall configuration
  • network segmentation
  • endpoint security
  • customer-managed wireless infrastructure
  • remote employee devices

The dealer still needs enough network knowledge to deploy and troubleshoot responsibly.

But “the access control system uses the network” does not automatically mean “the security dealer owns the customer’s entire network.”

That boundary should be clear.

Protecting Customer Administrator Accounts

A customer that administers its own users or doors also has responsibility for how it protects those administrator accounts.

That means considering:

  • who receives administrative privileges
  • whether employees share accounts
  • how access is removed when administrators leave
  • how customer-controlled devices are secured
  • whether privileges are broader than necessary

Cloud hosting cannot compensate for an administrator account that has been carelessly shared across an organization.

What Is the Security Dealer Responsible For?

The security integrator sits at an important point in the shared-responsibility model.

The dealer understands both the customer’s physical environment and the access control platform.

That creates responsibilities that go beyond mounting readers and connecting controllers.

Secure System Design and Installation

The basics still matter.

Dealers are responsible within their contracted scope for correctly installing and configuring the systems they provide.

That includes areas such as:

  • appropriate controller installation
  • locking hardware interfaces
  • reader installation
  • power
  • cabling
  • door monitoring
  • communication configuration
  • appropriate device placement

Cybersecurity does not replace good physical installation.

A cloud-hosted system connected to a poorly installed or incorrectly configured door is still a poor security system.

Access-Level and Schedule Configuration

When a dealer administers the system, configuration should reflect customer-approved requirements.

That includes:

  • access groups
  • schedules
  • holidays
  • door behaviour
  • temporary permissions
  • administrator privileges

The dealer should also avoid creating undocumented one-off exceptions that nobody understands six months later.

Standardized configuration becomes particularly important across multi-site accounts.

Administrator Account Management

Dealer-controlled administrator accounts need their own governance.

Ask:

  • Do technicians share a generic administrator account?
  • Does every technician need full administrative rights?
  • What happens when someone leaves the dealer?
  • Is remote access documented?
  • Are unnecessary privileges removed?
  • Is access provided to subcontractors?
  • How is that access later revoked?

The Canadian Cyber Centre’s cloud contract guidance specifically highlights the need to clearly divide responsibility for user accounts, permissions and identities in shared cloud environments.

The same principle should apply to a dealer’s own access.

Change Control

Remote administration makes it easier to make changes.

That means it also becomes more important to know:

  • who requested the change
  • who approved it
  • what was changed
  • when it was changed
  • whether it affected multiple locations

Good managed service is not simply fast administration.

It is controlled administration.

Customer Training

A dealer can configure a strong system and still create risk if customer administrators do not understand how to use it.

Training should cover the functions relevant to each role.

For example:

HR or office administrator

  • routine employee administration
  • credential status
  • proper offboarding process

Facilities

  • door schedules
  • basic operational information
  • proper support process

IT

  • network dependencies
  • responsibilities
  • escalation contacts

Security management

  • access reviews
  • events
  • reporting
  • exception management

This is why onboarding should be treated as part of the managed service, not just a short training session after installation.

What Is the Hosting or Managed Service Provider Responsible For?

When a dealer partners with a managed hosting provider, another responsibility layer is introduced.

The precise scope depends on the service agreement, but the hosting provider may be responsible for areas such as:

  • hosted application infrastructure
  • server environment
  • platform availability
  • infrastructure security controls
  • backup and recovery processes
  • infrastructure maintenance
  • hosted environment access
  • platform-level support
  • escalation
  • capacity and availability planning

Kantech describes hattrix as a hosted and managed access control solution that can remove the requirement for dedicated on-site access control servers while supporting remote management.

That changes the dealer’s operating model.

Instead of asking:

Who is maintaining the customer’s local access control server?

the conversation becomes:

What responsibilities are included in the hosted environment, and what remains with us and our customer?

Those responsibilities should not be assumed.

They should be documented.

Hosting Does Not Mean “The Provider Secures Everything”

This is one of the most important points for dealers to understand.

A hosting provider may secure the hosted infrastructure.

That does not mean the provider controls:

  • the customer’s employee list
  • who is granted warehouse access
  • the customer’s local network
  • the customer’s administrator laptop
  • the dealer’s technician accounts
  • the physical locking hardware
  • access decisions made by HR
  • undocumented changes made by a third-party contractor

Cloud security remains a partnership.

The Canadian Cyber Centre describes risk mitigation in managed and cloud environments as a shared responsibility between the organization and its service providers.

For dealers, that is not a weakness of cloud access control.

It is a reason to define the model properly.

What Is the Manufacturer Responsible For?

The manufacturer occupies another part of the security chain.

For Kantech deployments, the manufacturer is responsible for areas connected to its products and services, including product development, supported functionality, technical documentation, product updates and cybersecurity practices associated with its products.

Kantech currently maintains a Cyberprotection Program within its support resources and describes it as information covering its cybersecurity standards and how it secures its products and services.

The manufacturer can provide secure product capabilities.

The dealer still needs to deploy those capabilities responsibly.

This distinction matters.

A product can support appropriate security controls without guaranteeing that every deployment will be configured securely.

Likewise, a manufacturer update may be available, but somebody still needs a process for reviewing and applying the relevant update according to the system architecture and support model.

What Should Dealers Ask a Cloud Access Control Hosting Provider?

Choosing a hosting partner should involve more than comparing monthly pricing.

A dealer is placing part of the managed service it sells to customers into another company’s environment.

That means the dealer should understand how that environment is operated.

Here are ten useful questions.

1. Where Is Customer Information Hosted?

Ask where the hosted infrastructure and customer information reside.

For Canadian customers, this can matter for:

  • internal IT policy
  • procurement
  • contractual requirements
  • customer risk preferences
  • public-sector requirements
  • privacy assessments

Do not assume every customer has the same residency requirement.

2. What Independent Assurance Applies to the Environment?

Ask whether the provider has undergone relevant independent assessments or audits.

If the provider references SOC 2 or another assurance framework, ask:

  • what environment is covered
  • what services are in scope
  • what period the report covers
  • whether the claim applies to the service you are selling

A logo is not a substitute for understanding scope.

3. Who Can Access Customer Environments?

Ask:

  • which provider employees can access customer systems
  • why they need access
  • how privileged access is controlled
  • how employee access is removed
  • whether support access is logged

This is particularly important if your end customers ask detailed security questions.

4. How Are Dealer Administrator Accounts Managed?

Understand:

  • account creation
  • permission levels
  • account removal
  • support access
  • authentication requirements
  • how former dealer employees are removed

Your own team will be part of the security model.

5. How Are Backups and Recovery Handled?

Ask what is actually included.

Not:

“Do you have backups?”

Ask:

  • what is backed up
  • how recovery works
  • who initiates recovery
  • what expectations apply
  • whether restoration procedures are documented

The Canadian Cyber Centre recommends treating cloud security as a layered risk-management process rather than assuming cloud deployment itself solves security requirements.

6. How Are Security Updates Managed?

Understand the line between:

  • manufacturer updates
  • hosted application updates
  • operating environment
  • dealer-managed components
  • field hardware

If nobody can explain who manages an update, the responsibility is not clear enough.

7. What Happens During a Security Incident?

Ask:

  • how incidents are identified
  • what events trigger customer or dealer notification
  • who the dealer contacts
  • how escalation works
  • what information is provided
  • what responsibilities remain with the dealer and customer

Canadian Cyber Centre guidance for managed service contracting emphasizes clearly defined services, deliverables and responsibilities between the provider and customer.

8. What Logging or Audit Information Is Available?

Depending on the service, dealers or customers may need to understand:

  • administrative activity
  • access events
  • support activity
  • account changes
  • security events

Ask what the platform records and what information is available when a customer needs to investigate a change.

9. What Happens When the Customer Leaves?

Understand the offboarding process before the account starts.

Ask:

  • how access is removed
  • how dealer credentials are handled
  • what customer information can be exported
  • what information is retained
  • how the transition is coordinated

This should also be reflected in the dealer’s customer service agreement.

10. Who Supports the Dealer When a Problem Goes Beyond First-Line Support?

This is an operational question as much as a cybersecurity question.

The dealer should understand the escalation path when an issue involves:

  • hosting infrastructure
  • platform behaviour
  • software
  • communications
  • suspected security issue
  • manufacturer support

A hosting partner is most useful when its responsibilities are clear before the dealer needs them.

Does Canadian Data Residency Automatically Mean the Customer Is Compliant?

No.

This distinction matters because “hosted in Canada” and “compliant” are sometimes treated as interchangeable sales language.

They are not.

Canadian hosting can be an important consideration for organizations with:

  • internal data-residency policies
  • procurement requirements
  • contractual obligations
  • public-sector considerations
  • customer-specific risk requirements

However, the Office of the Privacy Commissioner of Canada does not treat outsourcing or foreign processing as automatically prohibited under PIPEDA. Organizations remain accountable for personal information under their control and need appropriate protections when using third-party providers.

The exact privacy requirements also depend on:

  • jurisdiction
  • industry
  • type of organization
  • type of information
  • contractual commitments
  • applicable federal or provincial law

Security dealers should therefore avoid statements such as:

“Your data is in Canada, so you are PIPEDA compliant.”

A better approach is:

“The environment is hosted in Canada, which may help meet your organization’s data-residency or procurement requirements. Your privacy and compliance obligations still depend on your own organization, information and applicable requirements.”

That answer is more accurate and more credible with sophisticated customers.

What Does SOC 2 Actually Tell a Dealer?

SOC 2 is another term customers may increasingly encounter when evaluating technology providers.

It is useful because it can provide independent assurance around controls within a defined service environment.

It should not be described as a universal security certification that makes every connected customer automatically compliant.

The practical questions for a dealer are:

  • Is the service environment actually within the SOC 2 scope?
  • Which controls are covered?
  • What period was evaluated?
  • Which responsibilities still belong to the dealer?
  • Which responsibilities still belong to the customer?

My Managed Security has published that its existing infrastructure and its planned SOC 2-certified environment are hosted within Canada, with the additional environment intended to support dealers pursuing customers with more formal security, procurement and compliance requirements.

For dealers, the value of that infrastructure story is not simply being able to say “SOC 2.”

The value is being better prepared when a customer’s IT or procurement team asks:

“What controls exist behind the service you are selling us?”

That is a more mature cloud sales conversation.

How Should Dealers Handle Administrator Accounts?

If there is one section of the shared-responsibility model worth turning into a standard dealer procedure, it is administrator access.

Create a process for four situations.

When a Customer Administrator Is Added

Document:

  • who approved the account
  • the person’s role
  • required privilege level
  • date access was added

When a Dealer Technician Is Added

Ask:

  • does this technician need access?
  • to which customer accounts?
  • at what level?
  • is the access temporary or ongoing?

Avoid granting broad privileges simply because it is easier.

When Someone Changes Roles

Access should be reviewed when an administrator changes responsibilities.

A facilities manager who becomes a regional manager may need different permissions.

A technician moving into sales may no longer require administrative access to customer systems.

When Someone Leaves

Removal should be part of offboarding.

Not:

“We will clean up accounts eventually.”

The process should answer:

  • who notifies the appropriate administrator
  • how quickly access is removed
  • whether shared passwords need changing
  • whether remote access needs review
  • whether customer environments need to be checked individually

This is basic governance, but it becomes much more important as a dealer’s managed customer base grows.

Ten customer environments are easy to remember.

Hundreds of managed doors across dozens of customer accounts require a process.

What Happens When a Customer’s Network Is Compromised?

This is a question dealers should expect from increasingly security-conscious customers.

The answer depends on the deployment.

Cloud-managed access control does not mean the customer’s local network becomes irrelevant.

Controllers, administrator devices and other connected equipment may still rely on customer-controlled infrastructure.

If the customer experiences a cybersecurity incident, the dealer may need to coordinate with:

  • customer IT
  • customer cybersecurity provider
  • hosting provider
  • manufacturer support
  • other technology vendors

The dealer’s role should be defined in advance.

Potential steps may include:

  • assessing whether access control communication is affected
  • reviewing relevant administrator access
  • helping the customer identify access-control dependencies
  • following the hosted-service escalation process
  • reviewing recent changes or unusual activity where appropriate
  • changing dealer-controlled credentials if required
  • coordinating restoration once customer IT confirms it is safe to do so

The dealer should not improvise an incident-response promise during the incident.

This is another reason the service agreement should identify cybersecurity and escalation responsibilities before go-live.

Can Cybersecurity Become a Competitive Advantage for Security Integrators?

Yes, but not by turning every salesperson into a cybersecurity consultant.

The advantage comes from being able to answer reasonable questions clearly.

Consider two dealers presenting the same access control opportunity.

Dealer A says:

“Don’t worry. It’s cloud-based and secure.”

Dealer B can explain:

  • where the service is hosted
  • what infrastructure the customer no longer needs to maintain
  • which responsibilities remain with customer IT
  • how dealer administrator access is handled
  • how users are added and removed
  • how support escalation works
  • what independent assurance applies to the hosted environment
  • where responsibilities between dealer and hosting provider are documented

Which dealer is more prepared for a conversation with the customer’s IT director?

That difference becomes increasingly important as physical security and IT overlap.

A strong security dealer does not need to know everything about cybersecurity.

The dealer needs to understand its part of the system well enough to know where its responsibility begins, where it ends and who owns the next layer.

That is professional managed service.

How Does the Managed Services Dealer Model Change the Responsibility Picture?

Security integrators interested in cloud-managed access control face an important business decision.

One option is to build the hosting capability themselves.

That means operating another layer of the service, potentially including:

  • hosted infrastructure
  • server environment
  • maintenance
  • platform support
  • backups
  • availability planning
  • security controls
  • recovery
  • customer capacity as the service grows

For some security companies, building that capability makes sense.

For others, it pulls resources away from the parts of the business they actually want to scale:

  • winning customers
  • designing access control systems
  • installation
  • field service
  • customer support
  • account management
  • recurring managed services

Kantech’s hattrix model supports hosted and managed access control, and My Managed Security positions its MSD offering around enabling Canadian security integrators to provide hattrix managed services without building their own cloud infrastructure.

That changes the responsibility model.

The dealer can remain responsible for the customer-facing areas it knows best while partnering with MMS for the hosted service layer defined within that relationship.

The result is not:

“MMS handles security, so the dealer doesn’t have to think about it.”

The better model is:

“The responsibilities are divided intentionally so the dealer does not have to build every operational layer itself.”

That is a much stronger foundation for managed access control.

A Practical Shared Responsibility Checklist for Dealers

Before onboarding a customer to cloud-managed access control, make sure your team can answer the following.

Customer Responsibilities

  • Who decides who receives access?
  • Who reports terminated employees?
  • Who owns the customer’s network?
  • Who can authorize access changes?
  • Who administers customer-side accounts?

Dealer Responsibilities

  • Who configures access levels?
  • Which technicians receive administrator rights?
  • How are dealer accounts removed?
  • How are changes documented?
  • How are support requests authenticated?
  • What remote-access methods are approved?

Hosting Provider Responsibilities

  • Where is the environment hosted?
  • Who can access it?
  • How is infrastructure maintained?
  • How are backups and recovery handled?
  • What is the escalation process?
  • How are security incidents communicated?
  • What independent assurance applies?

Manufacturer Responsibilities

  • Where are current product security resources located?
  • How are product updates communicated?
  • What products and versions remain supported?
  • What technical support path exists?

Contract Responsibilities

  • Are all of these boundaries reflected in the managed service agreement?
  • Does the customer know what the dealer manages?
  • Does the dealer know what the hosting provider manages?
  • Is offboarding defined?

If one of these questions consistently produces:

“I’m not sure.”

that is the responsibility to define before the account scales.

Frequently Asked Questions

Who is responsible for cybersecurity in cloud access control?

Cybersecurity is shared among the organizations involved. The customer is responsible for areas such as internal access policies and customer-controlled systems. The security dealer manages deployment and administration within its scope. Hosting providers manage responsibilities associated with their hosted environment, while the manufacturer is responsible for its products and product security programme.

Is cloud access control more secure than on-premise access control?

Neither architecture is automatically secure simply because of where the software is hosted. Security depends on system design, account management, network configuration, infrastructure controls, updates, processes and the responsibilities of everyone involved. Cloud hosting can shift certain infrastructure responsibilities to a specialized provider, but customer and dealer responsibilities remain.

Is access control data considered personal information?

Access control environments can contain information about identifiable individuals, including names, credentials, photographs, permissions and access-event histories. Whether particular information is considered personal information and which privacy requirements apply depends on the context and jurisdiction. Customers should evaluate their own legal and privacy obligations.

Does access control data have to stay in Canada?

There is no universal rule requiring every Canadian commercial organization’s access control data to remain in Canada. Requirements can vary by jurisdiction, sector, contract and organizational policy. Canadian hosting can still be valuable for customers with specific residency, procurement or risk-management requirements.

What does SOC 2 mean for a cloud access control environment?

SOC 2 can provide independent assurance concerning controls within the defined scope of a service organization and its examined environment. Dealers should understand what service and controls are actually included rather than treating SOC 2 as a blanket statement that every customer or deployment is automatically secure or compliant.

Who should manage cloud access control administrator accounts?

Responsibility depends on the service model. Customer administrator accounts may be controlled by the customer, while dealer and hosting-provider accounts are controlled within their respective organizations. The important requirements are clear approval, appropriate privileges, individual accountability where practical and prompt removal when access is no longer required.

What happens if a customer’s network is compromised?

The response depends on the system architecture and the nature of the incident. The dealer may need to coordinate with customer IT, the hosting provider and manufacturer support while reviewing access-control connectivity, administrator accounts and relevant system activity. Incident responsibilities should be established before an event occurs.

What cybersecurity questions should integrators ask a hosting provider?

Ask where customer information is hosted, who can access the environment, how privileged accounts are controlled, how backups and recovery work, how security updates and incidents are handled, what independent assurance applies, what logging is available and what happens to customer information when the service ends.

Cloud Security Is Stronger When Responsibilities Are Clear

Moving access control to the cloud can reduce local infrastructure, simplify remote management and give dealers new ways to support customers.

It does not make responsibility disappear.

The customer still needs good access policies.

The dealer still needs secure installation, configuration and administration.

The hosting provider still needs to operate a dependable and well-controlled environment.

The manufacturer still needs to maintain and support the products behind the system.

The strongest managed access control relationships are the ones where nobody has to guess which party owns the next step.

For security dealers, that clarity is also commercially valuable.

Customers with IT, procurement or governance requirements are more likely to trust a dealer that can explain its service model than one that simply says the platform is “secure because it’s in the cloud.”

My Managed Security helps Canadian security dealers deliver Kantech hattrix cloud-managed access control while partnering for the hosted infrastructure behind the service. MMS currently positions its Managed Services Dealer model around allowing integrators to build recurring cloud access control services without developing their own hosting environment from the ground up.

That allows the dealer to keep focusing on the parts of the relationship where it creates the most value: the customer, the doors, the installation, the service and the long-term managed security strategy.

Interested in offering cloud-managed Kantech access control without building the hosting infrastructure yourself? Talk to My Managed Security about becoming a Managed Services Dealer.


Recommended Internal Links

Add contextual internal links to: