Securing a room on the day it is installed is the easy part. Paul McNicholl, Business Development Manager at DisplayNote, considers what it takes to prove that every shared space stays secure over time, and why visibility and consistency matter as much as individual features.

A meeting room can be configured securely on the day it is installed. Applications can be restricted, settings locked down, browser behaviour controlled and security policies applied. The room can be tested, signed off and added to the estate with confidence.

The harder question is what happens afterwards.

Six months later, the operating system may have changed. An application may have been added. A local administrator may have altered a setting to solve a specific problem. A temporary exception may still be in place because nobody remembered to remove it. One room may have received an update while another has not. A configuration that once reflected policy may no longer reflect the organisation's current security requirements.

None of these things is unusual. Technology changes constantly, and shared spaces are no exception. The problem is not that change occurs, but that organisations can lose visibility of the difference between the state they intended and the state that actually exists.

That is where shared-space security moves beyond individual features and becomes a governance issue. Cleaning one room is a feature; ensuring every room remains clean, controlled and within policy is governance.

The distinction matters because security cannot be judged only by what a product is technically capable of doing. It also depends on whether an organisation can apply controls consistently, identify when they drift and prove that the environment is still operating as intended.

The more demanding question is therefore not whether a room was secure when it was installed. It is whether the organisation can prove it remains secure today.

Security controls are only as strong as their consistency

Most organisations can describe what a secure shared space should look like. Applications may be restricted. Users may be prevented from changing system settings. Sessions may be cleared after use. Approved network configurations may be defined. Software versions may be controlled and administrative access limited.

Individually, those controls are sensible. The difficulty begins when they are applied differently from one room to another.

One room may correctly clear session data while another is still running an older configuration. One office may restrict applications while a second has introduced a local exception. A newly installed classroom may follow the latest security policy while an older deployment reflects decisions made several years ago. The estate may still look secure on paper, but the operational reality becomes increasingly fragmented.

This is where configuration drift becomes more than a support issue. Drift occurs when the current state of a device moves away from the state originally intended. It may happen gradually and for perfectly understandable reasons: a workaround, an update, a new application, a hardware change or an urgent local requirement. Over time, however, those small decisions can create an estate in which equivalent rooms no longer behave in equivalent ways.

A security capability only becomes a security standard when it is applied consistently. Without that consistency, the organisation is not really managing a governed estate; it is managing a collection of individual rooms.

The assurance gap: intended, actual and verified

The challenge can be understood as a gap between three different states.

• Intended: How should every room be configured?

• Actual: How is each room configured now?

• Verified: Can we demonstrate the current state across the estate?

The first state is usually the easiest. Organisations can define standards, approve applications, specify security controls and document expected behaviour. The second is harder because real-world technology does not remain static. Software changes, hardware ages, users develop workarounds and local teams respond to operational pressure.

The third state is where genuine assurance begins.

An IT team may believe that every room is running a particular policy, but can it prove that belief? Can it identify rooms that have moved away from the approved baseline? Can it see where an exception exists, when a configuration was changed or whether a security setting has been applied everywhere it should be?

This is the difference between assumption and evidence.

In a small environment, experienced administrators often carry much of this knowledge informally. They know which room has the unusual setup, which device needs a different update path and where a workaround was introduced. That can work while the estate remains small and physically close.

Once rooms are distributed across multiple offices, campuses, schools or regions, that model becomes increasingly fragile. Knowledge has to move from individuals into systems.

Governance begins when the organisation can answer a simple question with confidence: what is the current state of the estate, and how do we know?

Why scale makes manual assurance unsustainable

The security of five rooms can be managed very differently from the security of 500.

With a handful of spaces, manual checks may be perfectly reasonable. An administrator can visit each room, compare settings, confirm software versions and correct inconsistencies directly. As the estate grows, that approach becomes less practical and eventually becomes an operating constraint.

Scale creates more than additional devices. It creates more combinations of software versions, hardware generations, policies, local settings, network conditions and user behaviours. Rooms may have been installed at different times, by different teams, against different technical standards. Some will be used heavily, others occasionally. Some may sit in one building, while others are spread across different sites or regions.

Each difference creates another potential state for IT to understand.

A large school district is a good example. It may operate hundreds of classrooms across multiple sites with a relatively small IT team. Displays may span several technology refresh cycles, with different operating systems, software versions and configurations across the estate. The same challenge appears in enterprise environments across offices, meeting rooms and collaboration spaces.

At this point, security assurance cannot depend on someone physically checking every device. If proving compliance requires walking the estate, the model is already difficult to scale.

The issue is no longer whether someone could inspect every room. It is whether manual inspection is a credible way to maintain policy in an environment that changes continuously.

Visibility is the foundation of control

One of the simplest principles in technology governance is also one of the most important: IT cannot effectively govern what it cannot see.

Visibility alone does not make a shared space secure. Monitoring a poor configuration does not improve it. What visibility provides is the ability to understand current state rather than rely on assumptions, user reports or retrospective investigation.

For a centrally governed estate, useful visibility might include device status, software versions, configuration state, policy status, connectivity, update status, exceptions and recent changes. The exact data required will vary by organisation, sector and risk profile, but the principle is consistent: administrators need sufficient insight to understand whether rooms are operating as intended.

This matters because security is not static. A room that was compliant yesterday may move out of policy tomorrow because of an update, a local change or a failed configuration push. Without visibility, that change may go unnoticed until somebody reports a problem or an audit exposes it.

Visibility therefore turns security from a deployment decision into an ongoing operational capability. It allows IT teams to compare the approved state with the actual state and focus attention where intervention is required.

That is the starting point for meaningful assurance.

Configuration consistency should be treated as a security control

Standardisation is often discussed in terms of efficiency. If every room behaves in broadly the same way, support becomes easier, training becomes simpler and users encounter fewer surprises.

The security benefit is just as important.

The fewer unique states an organisation supports, the easier it becomes to understand what normal looks like. In an estate where every room has been configured independently over several years, administrators may be responsible for dozens or hundreds of combinations of applications, permissions, operating systems and local settings. When something goes wrong, the first task is often working out how that particular room was configured in the first place.

A more standardised environment reduces the number of unknowns. Approved configurations can be defined, application access can be consistent and security settings can follow a common baseline. Where differences are necessary, they can be deliberate rather than accidental.

This does not mean every room needs to be identical. A boardroom, classroom and training space may legitimately require different workflows and capabilities. The important point is that those differences should be intentional, documented and governed.

Variation is not the problem. Uncontrolled variation is.

The more unique room configurations an organisation supports, the harder it becomes to know whether the estate is secure by design or merely secure by coincidence.

Auditability means proving that policy is operating

Security documentation is necessary, but documentation does not demonstrate implementation.

An organisation may have a policy stating that shared rooms should only run approved applications, that sessions should be cleared after use or that particular settings must remain locked. Those requirements describe intent, but assurance depends on whether the controls are actually operating.

Can the organisation establish whether the policy is applied across all rooms? Can it identify devices sitting outside the approved baseline? Can it show when a change occurred or confirm that a problem has been remediated?

Those questions matter because security assurance is increasingly evidence-based. Internal security teams want confidence that controls are working in reality. Customers and procurement teams may ask for proof of governance. Auditors may want to understand how standards are enforced across distributed estates.

The issue is no longer simply whether a policy exists, but whether the organisation can demonstrate that the policy is being applied.

For shared spaces, this creates a useful test. If evidence can only be gathered through manual room-by-room inspection, the governance model remains fragile. A more mature approach allows IT teams to demonstrate estate status centrally, identify deviations and document remediation without treating every room as a separate audit exercise.

Remote control changes the economics of security

Remote administration is often discussed as a support efficiency, and it certainly is one. Sending a technician to a room to reboot a device, change a setting or update software is inherently more expensive than carrying out the same intervention centrally.

But remote control also changes the economics of security.

Imagine a policy change that needs to be applied across 300 rooms. If every device requires physical intervention, the organisation faces an immediate trade-off between consistency and resource availability. Some rooms may be updated quickly, others later. Different sites may operate on different timelines and temporary inconsistency becomes unavoidable.

If the same change can be deployed centrally, the model changes. Policies can be applied consistently, known-good configurations can be restored and updates can be managed without waiting for somebody to visit every room.

The time between identifying a problem and resolving it also shrinks. A security control is considerably more valuable when it can be corrected across an estate in hours rather than addressed room by room over several weeks.

Remote management is therefore not simply convenient. It is one of the mechanisms that allows governance itself to scale.

Exceptions are inevitable; invisible exceptions are not

No large technology estate operates without exceptions.

A particular room may need a specialist application. An older device may require a temporary workaround. A customer environment may have an unusual network condition or an update may need to be delayed because of compatibility concerns.

The objective should not be to eliminate every exception. It should be to ensure exceptions remain visible, deliberate and owned.

That distinction separates flexibility from drift.

A mature governance model should make it possible to identify where an exception exists, understand why it was introduced and know whether it is still required. Temporary changes should not become permanent simply because nobody remembers that they were temporary.

This is particularly important for MSPs and channel partners supporting customer estates. The more undocumented variation accumulates, the more expensive and unpredictable those environments become to manage.

Central visibility and configuration control make exceptions manageable because they remain visible against the standard rather than disappearing into the estate.

What good shared-space assurance looks like

There is no single model appropriate for every meeting room, classroom or collaboration estate. Organisations have different risk profiles, regulations, operating models and technical architectures. Even so, good assurance tends to rest on a small number of principles.

• First, every room should begin from a known baseline appropriate to its role. That baseline establishes what normal looks like, including approved applications, relevant security controls and expected configuration.

• Second, IT needs central visibility. Teams should be able to understand the current state of the estate without physically inspecting every space.

• Third, equivalent rooms should operate under consistent policy. Where differences exist, they should reflect deliberate requirements rather than installation history or local improvisation.

• Fourth, changes should be controlled and traceable. Updates, policy modifications and configuration adjustments should follow a governed process so the organisation can understand what changed and why.

• Fifth, exceptions need to be visible and owned. A workaround should not become a permanent unknown simply because it solved an urgent problem at the time.

• Finally, organisations need evidence. Assurance ultimately depends on being able to demonstrate that controls are operating, not merely state that they should be.

Together, these principles move shared-space management away from room-by-room administration and towards genuine estate governance.

Why this matters particularly in education

Education provides a particularly clear example of why central assurance matters.

Schools and districts increasingly operate large numbers of connected classroom devices across multiple buildings, often supported by relatively small IT teams. Those environments are also dynamic. Teachers move between rooms, students connect different devices and displays may have been deployed across several technology refresh cycles.

The challenge is therefore not simply keeping one classroom working. It is maintaining a consistent technology environment across the estate.

That includes security.

If one classroom follows one set of policies and the next follows another, IT teams inherit greater support complexity and weaker assurance. Manual checks become less practical as the estate grows, while local variation becomes harder to detect.

This is precisely the operational challenge that central management is intended to address. DisplayNote's Montage Central Management Portal, for example, is designed to give education IT teams greater visibility and control across classroom devices, including the ability to monitor room and device status, manage configurations remotely and support greater consistency across multiple spaces.

The broader market shift, however, is more important than any single product. Education technology is moving from a model centred on individual classroom functionality towards one where IT teams increasingly need estate-level visibility, management and assurance.

The same transition is taking place across enterprise meeting-room environments.

From configuration to governance

The maturity of shared-space security can be understood as a progression:

• A configured room is secure today because somebody has set it up correctly.

• A standardised estate extends that baseline across equivalent rooms.

• A centrally managed estate gives IT the ability to see and control those environments remotely.

• A governed estate goes a step further by allowing the organisation to demonstrate that policies are being applied consistently and identify where exceptions exist.

The progression is important because many organisations stop at the first or second stage. They may have strong security controls inside individual rooms but limited ability to establish whether those controls remain consistently deployed over time.

That is the assurance gap.

Closing it requires more than additional room-level features. It requires management infrastructure capable of showing what is happening across the estate and maintaining a known state as technology changes.

Security you cannot prove is difficult to govern

Shared-space security should not become another exercise in manufacturing fear around connected technology. Most meeting rooms and classrooms will operate every day without a serious security incident, and overstating the risk would add little value.

The more important issue is whether organisations have an operating model capable of maintaining the controls they believe are already in place.

A room can be secure on deployment day and gradually move away from that state. Policies change, software updates, exceptions accumulate and configurations drift. At small scale, those changes may remain manageable through individual knowledge and manual intervention. At larger scale, they become an assurance problem.

The question therefore changes. It is no longer enough to know that a shared space was configured securely. Organisations increasingly need to know that it remains within policy and, crucially, that they can demonstrate this without walking the estate room by room.

That is what turns security from a feature into governance.

The strongest question to ask is no longer simply, “Are our rooms secure?”

It is: “Can we prove they are?”

How much visibility do you have across your shared-space estate?

DisplayNote helps organisations make meeting rooms and learning spaces easier to manage, easier to govern and more secure by design. If you’re reviewing how shared spaces are managed, governed or secured at scale, explore our security and governance approach or speak to the team.