A recent episode of AV Superfriends Off the Rails (Episode 134), featuring guests from AV Trust, brought to life the hard truth that most AV systems are not secured by design; they are simply overlooked. Frank brought up the old theory that if AV lives on its own network or stays out of sight, it is effectively protected. That idea has been convenient, and for a long time, it has appeared to work. But as AV continues to converge with IT infrastructure and expand its footprint, that assumption is becoming harder to defend.
Most AV teams do not think of themselves as running insecure systems. The gear works. The rooms are up. Support tickets get resolved. If someone asked whether their AV infrastructure was protected, the honest answer from most campuses would be some version of “it’s on its own network” or “you’d have to know where to look.” That answer feels reasonable until you examine what it means.
What it means is that the primary defense for many AV systems in higher education is that no one has yet tried to compromise them. That is not a security posture. That is security by obscurity. And it has been failing in every other area of technology for decades.
Security by Obscurity in Practice
The term “security by obscurity” dates back to the 19th century and aligns closely with Kerckhoffs’s Principle. This principle holds that a system’s security should depend solely on the secrecy of its key, not on its design. Early critics, such as Alfred Charles Hobbs, demonstrated how security rooted in secrecy often invites eventual exploitation. If the only thing standing between an attacker and access is the assumption that they will not discover the system exists, then the entire defense collapses the moment that assumption proves wrong.
In cybersecurity, that debate is settled. Obscurity as a primary strategy is broadly considered inadequate. Compliance frameworks like PCI Data Security Standard explicitly reject it, requiring organizations to implement strong, tested, industry-accepted protections rather than relying on proprietary or hidden mechanisms. The reasoning is consistent across the field: secrecy is fragile, discovery is inevitable, and systems must be built to withstand scrutiny rather than avoid it. And AV has not caught up to that consensus.
What We Actually Deploy
On most campuses, it is still common to find control processors with factory credentials. Touch panels with open web interfaces. DSPs are reachable over the network with no authentication because the device sits on a specific VLAN. Cameras with remote access enabled and no meaningful access control because the system was deployed under a deadline and nobody circled back. Firmware versions that have not changed since installation because the equipment is considered stable.
None of those decisions were made maliciously. Most of them were made under real pressure by teams that were focused on getting rooms online and keeping them running. But the cumulative effect is an environment where a significant number of connected devices are protected primarily by the hope that nobody will look.
Default credentials are published in product manuals. Device types can be identified through basic network scans. Management interfaces follow predictable patterns. Vendor documentation is publicly available. The “secret” in most AV obscurity strategies was never particularly secret to begin with.
AV vs IoT
A large portion of modern AV equipment behaves, from a network and security perspective, like IoT devices. They are embedded systems. They run specialized firmware. They expose web-based management, cloud connectivity, APIs, and remote services. They are deployed in volume. They are maintained inconsistently. They ship with convenience prioritized over hardened defaults. And they are managed by teams whose primary expertise is making rooms work, not defending endpoints.
In October, an article published on Shure’s website acknowledged this directly, noting that AV devices can serve as entry points for cyberattacks if not properly secured, turning everyday collaboration tools into organizational liabilities. That is not an exaggeration. It describes what happens when a class of connected devices is treated as operationally important but excluded from institutional security planning.
The IoT comparison matters because IoT security failures follow a pattern that maps almost exactly onto campus AV. Devices get deployed fast. Defaults stay in place. Patching is inconsistent or nonexistent. Monitoring is limited. Ownership is ambiguous. The devices work well enough that nobody questions their security posture until an incident forces the conversation. AV may not market itself as IoT, but from a risk management perspective, the overlap is significant and growing.
The Myth of the Island Network
AV teams have relied on the concept of isolated or islanded networks for years. The idea is that if AV devices live on their own separate infrastructure, they are insulated from the risks that affect the broader campus network. In theory, that sounds like a reasonable layer of protection. I completely agree with the thoughts from the podcast that, in practice, the island almost never exists as people describe it.
If the AV network depends on campus DNS, it is not an island. If devices authenticate against institutional directory services, it is not an island. If there is remote support access, vendor cloud connectivity, centralized monitoring, NTP synchronization, or any integration with building management or scheduling systems, it is not an island. If a technician can bridge into the AV network from a laptop connected to the campus wireless network, then it is not an island. If traffic crosses any infrastructure that the AV team does not exclusively own and manage, the boundary is not what it appears to be.
What most campuses actually have is a logically separated segment with varying degrees of access control, inconsistent rule sets, and limited visibility into what crosses the boundary. That is not isolation. That is segmentation with assumptions attached. And when those assumptions go unexamined, they create exactly the kind of false confidence that security by obscurity depends on. Teams believe they have built a defensible boundary when what they have actually built is a naming convention that discourages scrutiny.
Scale and Compliance in Higher Ed
Higher education makes all of this worse because of scale and complexity. A single classroom with default credentials is a manageable risk. Two hundred classrooms, fifty conference rooms, a dozen event spaces, simulation labs, health sciences environments, and athletics venues all running connected AV with inconsistent security practices are a different situation entirely.
The compliance dimension adds further weight. Lecture capture platforms handle student participation data. Conferencing systems may process authentication credentials. Recording and streaming workflows intersect with FERPA obligations. Health sciences AV may touch HIPAA-regulated environments. Even when an individual AV device does not directly store protected data, it may operate within an ecosystem where regulatory expectations apply. Compliance frameworks do not carve out exceptions for devices that are “just AV.” If the system is connected and handles institutional data flows, it falls within scope.
Accidental leaks, credential exposure, and reverse engineering can all negate the protection obscurity is meant to provide. In higher education, those risks are amplified by staff turnover, inconsistent documentation, multi-vendor environments, and the sheer number of people who interact with AV systems across a campus. The more people who touch a system over time, the less likely it is that any secret will stay secret.
AV professionals do not need to become security engineers. But they do need to stop treating invisibility as a control. They need to recognize that many of the products they deploy share more in common with IoT than with the isolated, self-contained systems of a decade ago. They need to let go of the idea that a separate network is the same thing as a secure network. And they need to build environments that hold up under examination rather than environments that depend on never being examined.
Because connected systems get found. Default credentials get discovered. Island networks turn out to have bridges. And the question is never really whether someone will look. The question is whether the system is ready when they do.
