Controlling Vendor Remote Access to Security Systems

Permanent third-party access can outlive the technician, contract or business need that originally justified it. IT and security governance leaders should require vendor access to be disabled by default, approved for a specific purpose, assigned to an identifiable person, protected with multifactor authentication, restricted to defined systems and privileges, logged, and automatically expired or promptly revoked when the work ends.

That policy applies to video management, cameras, access control, intrusion alarms, intercoms, cloud portals, mobile services and the infrastructure supporting them. The practical outcome is a repeatable permission contract and a set of acceptance tests. The organization can then prove who may enter, through which route, for what purpose, for how long, and with what evidence.

Start with every route a vendor can use

Build one inventory of remote-support paths before approving a technical design. A security platform can have several parallel entry points, and closing one does not govern the others.

Include:

• VPN, zero-trust network access and remote desktop gateways;
• vendor-cloud relays and device-management services;
• web portals for video, access control, alarms or intercoms;
• direct device web interfaces and public port-forwarding rules;
• unattended remote-support agents on servers or operator workstations;
• cellular modems, secondary internet circuits and out-of-band appliances;
• mobile applications and shared installer accounts;
• API tokens, service accounts, certificates and integration credentials;
• manufacturer support tools and integrator-managed monitoring platforms; and
• service laptops that bridge a corporate, cellular or vendor network into the security environment.

For each route, record the business owner, technical owner, vendor, support purpose, connected assets, identity provider, authentication method, privilege level, network path, data exposed, logging source, approval rule, expiry method and revocation owner. Trace the path from the external user to the final device. A vendor gateway that authenticates a person can still hand off to a shared administrator account inside the video or access-control platform, weakening attribution at the point where changes occur.

Look for dormant paths during the review. A previous integrator’s account, an unused cloud connector, a temporary firewall rule and a remote agent installed during commissioning can remain reachable after their purpose ends. Treat unknown access as an unresolved finding and contain it until ownership and necessity are confirmed.

Define the permission contract before enabling access

Every approved connection should be represented by a small, complete access record. The record gives operations, IT and the vendor the same understanding of the session.

Required field	Decision to record
Request and purpose	Work order, incident or change that requires access
Individual identity	Named technician and employer, including approved subcontractor status
Approver	Person accountable for the affected business and system risk
Scope	Sites, servers, controllers, cameras, doors or applications the technician may reach
Privileges	View, diagnose, configure, administer, export or update rights actually required
Time window	Start, expiry and approved extension process
Entry route	Approved gateway, managed workstation or vendor-cloud service
Endpoint requirement	Managed device, supported software, encryption and security-health expectations
Data handling	Whether video, cardholder data, alarm history, configuration or logs may be viewed or exported
Monitoring	Authentication, connection, administrative-action and change evidence to collect
Completion	Tests, records, rollback status and person who closes access

An approval should name the destination and privilege, rather than granting broad access to a security subnet. A technician updating recorder software may need server administration and vendor update services for a limited window. That task rarely requires access to every camera web page, door-controller database, employee roster or alarm history.

The contract should cover subcontractors and manufacturer escalation. If an integrator can invite another company into the system without customer approval, the organization loses control over the identity and purpose of the remote user. Procurement terms should require advance disclosure, equivalent controls, rapid personnel-change notification and customer-controlled removal.

Authenticate people and constrain privileges

Use a unique account for each human administrator and connect it to an identifiable individual. Shared vendor accounts make it difficult to distinguish technicians, remove one person’s access or investigate a disputed change. Separate human accounts from service accounts used by applications and integrations.

Require multifactor authentication for remote and privileged access wherever the platform supports it. The Canadian Centre for Cyber Security recommends MFA, least privilege, identifiable administrative accounts and logs that capture privileged actions, sign-ins, failures and account changes in its guidance on managing and controlling administrative privileges. The guidance has broad organizational scope. Each commercial platform still requires a product-specific implementation and recovery plan.

Divide permissions around real security-system functions:

• live video viewing;
• recorded-video playback and export;
• camera or analytics configuration;
• access-card and cardholder administration;
• door schedules and lockdown functions;
• alarm-zone bypass and panel programming;
• intercom directory and call-routing changes;
• user, role and identity-provider administration;
• firmware, server and database maintenance; and
• backup, restore and evidence deletion.

Grant the smallest combination needed for the approved work. The manufacturer’s role labels may be too coarse for the organization’s policy. Document that limitation and add compensating controls such as a supervised session, narrower network scope, a dedicated temporary account or a shorter access window.

Vendor documentation can expose useful product-specific controls. For example, the official AXIS Device Manager security guide recommends creating temporary device accounts for maintenance instead of disclosing a device’s root password, then deleting those accounts when work finishes. That is manufacturer guidance for a particular tool and device family. Apply the underlying lifecycle question to every selected product: can the organization issue, limit and remove a technician’s access without disrupting application credentials?

Route sessions through a managed access boundary

Use one organization-approved entry path where practical. A VPN, zero-trust access service or vendor-cloud relay can provide the encrypted connection. A managed jump host or dedicated administration workstation can constrain tools, destinations and data movement while concentrating evidence.

NIST Special Publication 800-53 Revision 5 defines remote-access controls that include prior authorization, automated monitoring, encrypted sessions and routing through managed access-control points. It also links remote access to account management, access enforcement, authentication and audit controls. See the official NIST SP 800-53 Rev. 5 publication. The catalogue is US federal guidance, so organizations should tailor its controls to their environment, obligations and risk tolerance.

A controlled boundary should support these design decisions:

1. Remote administration reaches a management zone or jump host first.
2. Firewall or access policy permits only the approved destination systems and services.
3. The vendor cannot route into unrelated corporate, tenant or building networks.
4. Administrative interfaces are unavailable directly from the public internet.
5. Internet egress from the security environment is limited to documented services.
6. Idle and maximum session limits close abandoned connections.
7. Access expires automatically when the approved window ends where the tools permit it.
8. Security monitoring receives useful authentication and connection events.

Vendor-cloud access needs the same governance. The official AXIS Device Manager Extend documentation illustrates why feature-level review matters: it documents remote-service activation, outbound destinations and ports, organizational roles, user invitations, MFA and user removal. Those details can change with versions and do not describe other manufacturers. Ask each vendor for the current architecture, data flow, identity model, service dependencies and customer-controlled disablement steps, then validate them in the deployed configuration.

The physical installation should reinforce the boundary. Plan recorder, controller, switching, firewall and management connections with the networking and data-wiring service so cabling and network placement support the approved architecture.

Make vendor access temporary by design

Time limits reduce the period during which a stolen credential or forgotten account can be used. Routine support access should open shortly before the approved work and close when the task or window ends. Extensions should require a new reason and approver.

Choose the strongest time-control method the system supports:

• just-in-time activation tied to an approved request;
• identity-provider group membership with automatic expiry;
• a temporary account with an expiry time;
• a gateway policy limited to a maintenance window;
• a one-time credential or short-lived certificate; or
• manual enablement and disablement verified by two people when automation is unavailable.

An always-on managed service may need persistent connectivity for health monitoring or alarm handling. Separate the application connection from human administration. Constrain service accounts to documented functions and destinations, monitor their behaviour, rotate credentials, and review continued need at a fixed interval. Human privileged access should still use a named and approved session.

Define emergency access before an outage. A break-glass process should identify who may request it, who authorizes it, which route and privilege it activates, how quickly it expires, what alerts are generated and when a post-session review occurs. Store recovery material securely and test the process without exposing the credential during routine work.

Collect evidence that supports operations and investigation

Useful logging connects business approval with technical activity. Capture enough information to answer who connected, under which authorization, from where, when, to what, what changed and when access ended.

Collect, where supported:

• request or ticket identifier and approver;
• unique vendor identity, organization and authentication result;
• source device, source address and access gateway;
• session start, end, timeout and termination reason;
• destination systems and services reached;
• successful and failed privileged actions;
• account, role, policy and credential changes;
• firmware, configuration and software changes;
• video, report, cardholder or configuration exports;
• remote-tool installation or execution; and
• access revocation and any residual connection attempt.

Send important events to a protected central log service where feasible. A privileged user with control of the managed device may also control local logs. The official AXIS OS knowledge base describes device audit logs for account activity and configuration changes and recommends remote syslog for longer-term storage, analysis and notifications. Its implementation applies to supported AXIS OS versions. Confirm equivalent logging, export formats, time synchronization and tamper protections for every platform.

Set retention from actual purposes such as support quality, change accountability, incident response, insurance, contractual requirements and legal advice. Logs can contain personal and operational information. Limit access, avoid collecting passwords or encryption keys, and document lawful handling. Session recording may be useful for high-risk changes, provided the organization assesses proportionality, notice, storage and privacy requirements.

Tie remote work to change control and recovery

A secure login does not make an unplanned change safe. Remote maintenance should follow the same technical change process as onsite work.

Before access opens:

1. identify the affected assets and current versions;
2. record the intended change and expected service effect;
3. capture a tested configuration backup where supported;
4. define a rollback point and responsible person;
5. confirm coverage or operating procedures during disruption; and
6. schedule business and security stakeholders who must validate the result.

After the work, require the vendor to document commands or configuration actions at an appropriate level, software and firmware versions, exceptions, observed failures and rollback status. Compare the work record with platform and gateway logs. Close the access only after required service checks pass.

Integrated systems deserve coordinated testing. A change to identity, networking, certificates or time services can affect cameras, door controllers, alarms and management clients at once. Review the dependency map for the full commercial security system before a vendor changes shared infrastructure.

Revoke every access element when the relationship changes

Revocation should be triggered by completion of work, a technician leaving the vendor, a subcontractor change, contract termination, a security incident, product replacement or a transfer to another service provider.

Use a checklist that reaches beyond the visible user account:

• disable or delete named human accounts;
• remove identity-provider memberships and federated trust;
• revoke invitations, sessions, tokens, certificates and API keys;
• rotate shared or recovery secrets that the vendor could know;
• remove remote agents, cloud connectors and management appliances no longer required;
• close firewall rules, allowlists, VPN profiles and cellular paths;
• transfer platform ownership and licensing administration;
• verify that service accounts still have a documented owner and need;
• preserve relevant logs and change records; and
• test that the former route and credential can no longer connect.

Assign each item to an internal owner. Vendor confirmation supports the record, while the customer should verify controls under its authority. Include revocation deadlines and cooperation duties in the service agreement so an urgent personnel or incident response does not depend on informal goodwill.

Acceptance tests should prove both access and denial

Run the tests during commissioning, after material upgrades, when vendors change and at a risk-based review interval. Capture the tester, date, platform version, policy version, evidence and result.

Ask the implementation team to demonstrate:

1. an unapproved vendor account cannot start a remote session;
2. a named approved technician can authenticate with MFA through the required gateway;
3. the session can reach only the approved systems, sites and services;
4. the assigned role cannot perform an excluded function such as video export or user administration;
5. access fails outside the approved window and closes at expiry;
6. gateway, application and device logs identify the individual and relevant actions;
7. failed authentication and attempted access to an excluded destination generate evidence;
8. a configuration change produces a work record, system evidence and successful rollback test where required;
9. a terminated session cannot reconnect with the same expired approval; and
10. removing the vendor identity, token, certificate or gateway rule blocks the former access path.

Test emergency access separately. Confirm authorized recovery under realistic conditions, immediate alerting, short expiry and a complete after-action record. Record product limitations as open risks with an owner and treatment date.

Questions to put in the vendor review

1. List every remote-access service, account, agent, cloud relay, port and data flow required by the proposed solution.
2. Can the customer disable remote access without affecting local recording, door operation or alarm processing?
3. Can every technician use a unique identity and MFA, including manufacturer and subcontractor personnel?
4. Which privileges can be separated for live view, playback, export, configuration, user administration and firmware work?
5. Can access be approved for a specific site, asset and time window with automatic expiry?
6. Which logs identify the individual, source, destination, administrative action, export and configuration change?
7. Can logs be sent to a customer-controlled service with synchronized timestamps?
8. What happens to access when a technician leaves, the contract ends or the customer changes integrators?
9. Which credentials, certificates, tokens, firewall rules and installed agents must be revoked during offboarding?
10. Which acceptance tests will the vendor perform, and what evidence will the customer receive?

A good remote-support design gives vendors enough controlled access to resolve problems while preserving customer ownership, accountability and recovery. Securitron Canada can help map the security-system architecture, network boundary and commissioning tests for a commercial facility, with the final access policy approved by the organization’s accountable IT and security leaders.