Zero Trust has become a mainstream principle for identities, devices and networks, but the meeting room is often left outside it. Luke McSorley, Head of Product at DisplayNote, explains how the same thinking can be applied to shared spaces without making them harder to use.

For much of the past decade, Zero Trust has moved from being a specialist cybersecurity concept to a mainstream architectural principle. Organisations have become more cautious about broad permissions, persistent trust and the assumption that a user or device is safe simply because it sits inside the corporate network.

The logic is straightforward. Access should be appropriate to the task, limited to what is necessary and governed continuously rather than granted implicitly. Identities should be verified, privileges constrained and systems designed so that a compromise in one area does not automatically create access to another.

Yet one environment can still sit awkwardly outside that model: the shared meeting room or classroom.

These spaces increasingly run operating systems, conferencing applications, browsers, wireless sharing services and cloud integrations. They connect to corporate and guest networks, interact with identities and are used by employees, customers, partners, teachers, students and visitors throughout the day. In technical terms, they are no longer passive AV environments. They are software-enabled spaces inside the wider technology estate.

The question, therefore, is not whether every meeting room should suddenly be treated like a laptop. It should not. The more useful question is whether the principles of Zero Trust should extend into environments where persistent trust is increasingly difficult to justify.

Zero Trust is an operating principle, not a product

One of the problems with Zero Trust is that the term is often used as though it describes a specific technology or security product. In practice, it is better understood as an architectural and governance philosophy.

At its core, Zero Trust challenges the idea that access should be trusted merely because somebody is on the right network, using an approved device or physically inside the organisation. The underlying principles vary between frameworks, but they broadly converge around a familiar set of ideas: verify access explicitly, grant only the privileges required, reduce persistent trust, assume compromise is possible and limit the consequences when something goes wrong.

Applied badly, this can sound like a recipe for more friction. Users face more authentication prompts, more restrictions and more steps to get simple tasks done. Applied well, however, Zero Trust should do almost the opposite. Controls become more precise, access is limited to what is relevant and security is designed into the environment rather than layered on afterwards.

That distinction is particularly important in shared spaces.

The goal should not be to make somebody prove their identity at every stage of a meeting or lesson. Nor should organisations try to copy the security model of a personal device onto a room that may be used by dozens of people every day. Instead, they should ask a more practical question: what unnecessary trust exists in the room today, and can it be designed out?

That creates a much more useful technical conversation.

Shared rooms are unusual security environments

A typical employee laptop has a persistent relationship with its user. The operating system knows who they are, their identity is authenticated, permissions can be linked to their role and security policies are associated with the device and the person using it.

A shared room is fundamentally different.

The person using it at 9am may have no relationship with the person using it at 10am. An employee might be followed by an external customer, who is followed by a consultant, who is followed by an executive. In a classroom, different teachers may use the same screen throughout the day while students and visitors connect their own devices.

The hardware is persistent, but the identities are temporary.

That distinction matters because shared spaces combine several characteristics that make persistent trust difficult to justify. Physical access is broad. User identity changes constantly. Browsers and applications may be shared. Guest devices may connect. Network access may cross boundaries. Sessions begin and end repeatedly.

None of that makes the room inherently insecure. It simply means the architecture should be designed around the fact that one user should not inherit the trust state of another.

A useful model is to separate what should persist from what should not. The room configuration may persist. The user's session should not. Approved applications may remain. The user's credentials should not. The device identity may remain visible to IT. The person's access should end when their interaction ends.

That is where Zero Trust begins to make practical sense in a shared environment.

Principle one: apply least privilege to the room itself

Least privilege is usually discussed in relation to users and accounts, but the same principle can be applied to a room.

A meeting space generally exists for a relatively defined set of purposes. People need to start meetings, join conferencing services, present content, collaborate and perhaps access a small number of approved applications. A classroom has similarly defined workflows around teaching, sharing and participation.

That does not necessarily mean the underlying device needs to behave like an unrestricted desktop computer.

If users can install software, change system settings, access administrative functions or alter the room configuration, the environment has more capability than its intended purpose requires. Zero Trust asks whether that excess capability is necessary.

A more deliberate design might expose Microsoft Teams, Zoom, Google Meet, Webex, wireless sharing and other approved tools while restricting operating system access and administrative functions. The precise configuration will differ from one organisation to another, but the principle remains consistent.

A shared room should provide enough capability to do the job without exposing capability that the job does not require.

This can improve usability as well as security. An unrestricted desktop may appear flexible, but flexibility can create confusion. Users are presented with options they do not need, settings can be changed and each room can gradually develop its own quirks.

Restricting the environment to the workflows people actually need can therefore remove both technical exposure and user friction.

Principle two: treat every session as temporary

The most obvious difference between a shared room and a personal device is that the room should not retain a meaningful digital relationship with the previous user.

That requires more than simply asking people to sign out.

A Zero Trust approach should treat every meeting or lesson as a bounded session with a clear beginning and a clear end. During that session, a user may authenticate to a conferencing service, open a browser, access cloud content or interact with an application. Those actions may be entirely appropriate while the session is active.

They do not necessarily need to survive it.

This means thinking deliberately about authenticated state, browser information, application sessions, temporary files and other artefacts created during use. If one user can unintentionally inherit the state of the person before them, the room has allowed trust to persist beyond the context in which it was originally granted.

Automatic logout, session reset, browser clean-up and application reset all help reduce that exposure.

A useful design principle is: The room should have memory for the meeting, but not memory of the meeting.

This also recognises the realities of human behaviour. People forget to log out. Meetings overrun. Teachers move between rooms quickly. Executives do not conduct security checks before leaving a boardroom.

Security that depends on every user performing perfect clean-up will always be inconsistent. A controlled end state is therefore stronger than relying on instructions.

Principle three: make connectivity deliberate

The networking requirements of collaboration spaces can be complex. A room may need to communicate with conferencing platforms, corporate services, guest networks, cloud applications and wireless presentation devices. In education, teachers and students may sit on different network segments. In enterprise environments, guests may need to share content without receiving broader access to internal systems.

The wrong response is to assume security means isolating the room completely.

A room that cannot reach the services it needs is not secure; it is unusable.

The more useful objective is deliberate connectivity. Network segmentation can help organisations control which systems communicate and under what conditions. VLANs, firewall policies and application-aware controls can reduce unnecessary connectivity between shared-room technology and the wider estate.

There is no single architecture that suits every organisation, and the aim should not be segmentation for its own sake. The principle is simpler than that: A shared room should be able to reach what it needs without inheriting unnecessary access to everything around it.

This becomes particularly important when wireless sharing is introduced. Users expect devices to connect easily, but the network should not have to be weakened simply to make that experience possible. Cross-network presentation and discovery need to be designed deliberately rather than solved with broad access rules.

This is where security architecture and user experience meet. The best implementation allows the teacher, presenter or guest to connect easily while preserving the boundaries IT has created for good reason.

Zero Trust, in this context, is not about blocking collaboration. It is about enabling it without granting more access than the interaction requires.

Principle four: central policy should override local improvisation

One of the biggest threats to any security architecture is the gradual accumulation of exceptions.

A room is installed with a standard configuration. Later, somebody needs a new application. Another space requires a workaround. A local administrator changes a setting. A platform update forces an adjustment. A temporary exception becomes permanent.

Five years later, the organisation may still describe the estate as standardised even though individual rooms behave very differently.

Zero Trust becomes difficult to enforce when local configuration can quietly override central policy.

That means shared-space security needs a control plane. IT should be able to define appropriate rules around applications, permissions, session behaviour, configurations and other relevant settings without manually rebuilding those controls room by room.

Central policy enforcement matters for two reasons.

The first is consistency. A security control should not exist in one office and disappear when an employee walks into an equivalent room somewhere else.

The second is scalability. If a policy needs to change across 500 rooms, the organisation should not depend on 500 individual interventions.

This also changes the meaning of compliance. A written policy that says a room must operate in a particular way has limited value if the organisation cannot establish whether that configuration is actually present.

Governance requires the ability to move from: “This is how the rooms should be configured”

to: “This is how the rooms are configured.”

That gap is where central management becomes strategically important.

Principle five: identity needs different treatment in shared environments

Identity is one of the foundations of Zero Trust, but shared rooms complicate the model because most enterprise identity systems are designed around persistent relationships between users and devices.

Shared spaces break that relationship. The room has one identity within the infrastructure. The person using it has another. Those identities should not be confused.

A room may need a persistent device identity so it can be managed, monitored and trusted appropriately by backend systems. The user, by contrast, may only need temporary access to a specific application for the duration of a meeting or lesson.

That creates several architectural considerations. Shared accounts should be used cautiously because they make accountability difficult and encourage persistent access. Personal authentication should not result in credentials being retained after the interaction ends. Administrative identities should be separated from everyday room use. Guest users should receive the minimum access required to participate rather than broad access to the environment.

The key distinction is between the identity of the room and the identity of the person temporarily using it.

Those identities have different purposes and different lifecycles.

This becomes increasingly important as shared spaces connect to more cloud services. A browser session, conferencing application or collaboration account may carry access far beyond the physical room itself.

The security boundary cannot simply be the door. Identity needs to be controlled according to the context in which it is being used.

Principle six: assume things will drift and design for recovery

Zero Trust is often discussed mainly in terms of preventing unauthorised access, but the equally important question is what happens when the environment moves away from its intended state.

Software updates fail. Configurations change. Applications behave unpredictably. Operating systems evolve. Platform vendors alter APIs and security requirements. Users discover edge cases nobody anticipated.

No environment stays perfectly static.

A resilient shared-space model therefore needs a mechanism for returning to a known-good state. That might involve remote configuration, automated reset, controlled update deployment, rollback capability or standardised room templates. The exact mechanism will vary, but the principle is that recovery should be predictable.

If an administrator discovers that a room is behaving incorrectly, they should know what the correct state looks like and have a repeatable way of restoring it.

At enterprise scale, this becomes essential.

An estate of hundreds of individually customised rooms is extremely difficult to secure because nobody can confidently describe what "normal" looks like. A governed estate creates a baseline. Deviation can then be identified and corrected.

This has security benefits, but it also has operational ones. Standardised environments reduce troubleshooting time, make support more repeatable and lower the number of unique failure scenarios IT teams need to understand.

Security and reliability are therefore not separate concerns. Both benefit from reducing unnecessary variation.

Zero Trust should not mean more user friction

At this point, it would be easy to conclude that a Zero Trust meeting room means more restrictions, more authentication and more technology between the person and the task they came into the room to complete.

That would be the wrong outcome.

A shared space exists to support human activity. People walk into meeting rooms to present, collaborate and make decisions. Teachers enter classrooms to teach. The room succeeds when the technology enables those activities without becoming the focus.

Security should follow the same principle.

The strongest controls are often the ones users barely notice. A presenter does not need to know that applications have been restricted centrally if the tools they need are already available. They do not need to manually clear session data if the room does it automatically. They do not need to understand the network architecture if the sharing experience works across the required boundaries without exposing unnecessary access.

This is why security and usability should not be framed as opposing goals.

In a well-designed shared space, Zero Trust can actually reduce friction because it removes ambiguity. The user sees a predictable interface. Approved applications are easy to access. The room returns to a known state. IT can manage the environment consistently.

The result is not a more complicated room. It is a more controlled one.

What this means for IT, MSPs, channel partners and display vendors

The practical implications differ depending on where an organisation sits in the collaboration ecosystem.

• For IT Operations, the key question is whether room security policies can be applied consistently and managed centrally. If every space requires individual intervention, the model will become increasingly difficult to sustain.

• For security teams, the question is whether shared spaces are represented in the organisation's Zero Trust architecture. Identity, network access, application control and session behaviour should be visible enough to govern appropriately.

• For MSP architects and channel influencers, the issue is architectural repeatability. A solution should not simply pass a security review at deployment. It should remain governable across multiple customers, sites and technology generations.

• For display vendor product teams, Zero Trust reaches into platform design. Embedded software increasingly needs to support policy enforcement, secure identity handling, lifecycle control and predictable recovery. A product that cannot support those requirements may eventually become difficult to position in enterprise, education or regulated environments.

The wider lesson is that Zero Trust in shared spaces is not a feature list. It is an architectural approach.

Zero Trust should follow the technology

Meeting rooms and classrooms have changed significantly in a relatively short period of time. They now run software, connect to cloud services, handle user identities, interact with multiple networks and depend on continuous updates.

The security model should evolve with them.

That does not mean every shared space needs the complexity of a high-security workstation, nor does it mean the same controls should be applied indiscriminately everywhere. Security should remain proportionate to the environment and the risk.

But historical ownership boundaries should not determine where Zero Trust stops.

If a room can access organisational services, handle identities and interact with networked applications, the same architectural principles that govern the wider estate deserve to be considered there too.

Least privilege, temporary sessions, deliberate connectivity, central policy, appropriate identity handling and predictable recovery are not excessive controls for a modern shared space. They are increasingly part of what makes that space manageable, scalable and trustworthy.

The question is therefore not whether every meeting room should become a cybersecurity project.

It is whether unnecessary trust is still built into an environment that no longer needs it.

How far does Zero Trust extend across your shared spaces?

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 Zero Trust principles apply beyond traditional endpoints, explore our security and governance approach or speak to the team.