Give Every Connected AV Device a Clear Owner

Every connected AV device needs a named owner, a defined purpose, and a plan for its full service life. Without those basics, teams may miss security notices, delay patches, or leave old accounts and network access in place.

Facilities may buy the display. An integrator may configure the camera. The codec may use a cloud service. The network team can see the traffic, while the service desk has no record of the room. When a vulnerability notice arrives, no one knows who must act.

Clear governance prevents that confusion.

Virginia’s IT policy library(opens in new tab) includes SEC530 resources, system security plan templates, risk treatment tools, and defined security roles. Requirements vary by entity and system. NIST’s NCCoE guidance on trusted device onboarding and lifecycle management(opens in new tab) also offers a useful model for connected AV, though not every AV device qualifies as IoT.

Create a Basic Governance Record

For each connected component, record:

• Device type, manufacturer, model, serial number, and asset ID
• Physical location and room service
• Business owner, technical administrator, and support group
• Network identity, segment, addressing method, and expected services
• Data the device captures, displays, stores, or transmits
• Cloud, API, mobile app, and vendor dependencies
• Firmware and configuration versions
• Credentials, certificates, and authentication method
• Logging, monitoring, backup, and recovery details
• Support status, vulnerability notice source, and end-of-life date
• Approved remote access method and external support contacts

Use the organization’s current asset, configuration, and risk systems when possible. A separate AV spreadsheet can become outdated fast.

Document Expected Network Behavior

NIST’s device characterization guidance(opens in new tab) stresses the need to understand expected and allowed network communications. The rule for AV is simple: each room device should communicate only with the systems required for its approved function.

Before deployment, document:

• Destinations
• Ports and protocols
• DNS requirements
• Time services
• Update services
• Management platforms
• Remote support access

Compare live network behavior with this baseline. An unexpected connection may have a valid purpose, but the device owner should be able to explain it.

Use network segmentation and least-privilege policies that fit the environment. Do not place devices on a broad, trusted network simply because no one has classified them.

Treat Onboarding as a Controlled Event

Review each device before it joins the production network.

Require:

• An approved model
• Supported firmware
• Unique credentials
• Changed default passwords and settings
• Disabled unused services
• Valid certificates
• Asset registration
• Approved network policy
• Monitoring enrollment

Test the configuration in a staging environment when possible. Record who accepted the device and how teams can rebuild it. If onboarding needs a temporary exception, assign an owner and expiration date.

Assign Work Across Teams

Each team should know its role:

• Business or system owners accept service risk and set priorities.
• Security teams define controls and incident requirements.
• Network teams manage and enforce connectivity.
• AV teams or integrators maintain functional configurations.
• Facilities teams coordinate physical access and equipment lifecycle.
• Procurement teams include security and support requirements in contracts.
• Manufacturers provide security notices, updates, and fixes.

Create a RACI for:

• Patching
• Credential rotation
• Certificate renewal
• Alert response
• Remote vendor access
• Configuration backup
• Incident containment
• Device retirement

“Shared responsibility” has little value unless the organization assigns each task to a person or team.

Patch Without Disrupting Room Service

AV firmware updates can affect audio processing, camera behavior, control drivers, and interoperability. A sound patch process should include:

• Vulnerability intake
• Severity review
• Lab or prototype testing
• Maintenance windows
• Rollback procedures
• Post-change acceptance tests

Concern about room disruption should not cause permanent delays. If the team cannot install a supported fix, document the added controls, the person who accepted the risk, and the date for review.

Control Remote Support

Vendor and integrator access should require approval, expire after a set time, use strong authentication, and create an activity log. Remove access when the work ends.

Avoid permanent shared accounts and unmanaged remote-control appliances. Define how the organization grants, monitors, and reviews emergency access.

Contracts should require:

• Prompt security notices
• Secure handling of configurations and data
• Named support contacts
• Cooperation during security incidents
• Clear remote access controls

The public entity remains responsible for governance, even when a vendor provides support.

Include AV in Incident Response

Add networked AV systems to plans for detection, triage, containment, evidence preservation, recovery, and communications.

Run a tabletop exercise based on a clear event: a room controller starts unusual outbound communication during a public meeting. Ask:

• Who can isolate the device?
• Can the meeting continue without it?
• Who contacts the vendor?
• Does the team have a known-good configuration?
• Who approves the device’s return to service?

The answers will show whether the inventory, support plan, and ownership records work in practice.

Retire Devices Deliberately

When a device leaves service, remove:

• User and service accounts
• Certificates
• Cloud registrations
• Remote access
• DNS records
• Monitoring entries
• Stored media and data
• Saved configurations
• Network policies

Follow approved data removal and disposal procedures. Update the room records and keep proof that the organization completed the retirement process.

Measure Whether Ownership Works

Track the percentage of connected AV assets with:

• A complete owner record
• Supported firmware
• A current configuration backup
• An approved network policy
• Active monitoring
• A vulnerability notice source
• A planned retirement date

Report overdue patches and expired exceptions by accountable owner, not only by device count.

Use Procurement as a Security Control

New solicitations should require:

• A supported product lifecycle
• Security documentation
• Vulnerability notices
• A secure update method
• Configurable services
• Logging features
• Remote access controls
• Data removal guidance

Before selection, require vendors to disclose cloud dependencies and end-of-support policies.

Check the Inventory in Person

Regularly inspect a sample of rooms. Compare the installed equipment with asset records and the network view.

Teams may add adapters, control processors, wireless sharing devices, or vendor support appliances over time. Routine checks help the organization find these changes and correct its records.

Leaders should be able to ask three questions and get prompt answers:

1. Who owns this device?
2. What should it do?
3. How will we recover it?

Test those answers during the annual risk review and after each major room upgrade.

VIcom helps Virginia public entities coordinate AV, UC, network, managed services, and cybersecurity needs from system design through ongoing support. Public entities should confirm current contract vehicles with their procurement officials.

Connect with us by filling out the form below.