Navakatha

Extended reality (XR) devices are not “just another screen.” They are computers that only work by continuously sensing the world.

A laptop can be secure with the camera shutter closed and the microphone muted. An XR headset cannot do its core job without tracking your head, hands, and often your environment. That single design fact creates a new security and privacy reality for workplaces: you are deploying endpoints whose default posture is “sensors on.”

If you treat XR like a novelty peripheral, you will get surprised. If you treat it like a sensor-rich corporate endpoint with a complicated data supply chain, you can make it boringly safe. Boring is the goal.

Explained in seconds

XR in the workplace creates three big risk shifts:

• More data types: video, depth, spatial maps, audio, hand tracking, eye tracking, and movement patterns.
• More places data can leak: apps, browsers, remote-assist tools, cloud syncing, and shared headsets.
• More ways to infer sensitive info: even “anonymous” motion and gaze signals can identify people or reveal what they are doing.

Mitigation is layered: policy + device management + identity controls + app allowlists + data minimization.

What XR “sees” at work (and why it matters)

Most enterprise XR scenarios (training, remote assistance, design review, guided maintenance) rely on some mix of:

• World-facing cameras and microphones for passthrough and collaboration.
• Depth sensors and simultaneous localization and mapping (SLAM), meaning the device builds a 3D understanding of spaces so digital content can stick to real surfaces.
• Hand and controller tracking.
• Eye tracking (in some devices) for foveated rendering, interaction, and analytics.
• Inertial measurement unit (IMU) motion sensors that capture fine-grained head and hand movement.

Those signals are operational gold, and also security and privacy explosives if mishandled. The WebXR Device API, for example, explicitly calls out that immersive capabilities introduce unique security and privacy risks because they expose powerful sensing and tracking to web content.

The risk map: what can go wrong in real workplaces

Bystander privacy and “ambient capture”

A headset used on a factory floor or in an office can unintentionally capture faces on whiteboards, badges, screens, prototypes, or customer data. Even if you ban recording, collaboration apps may transmit sensor-derived streams.

This is not just about “someone took a video.” It is about continuous capture as a default mode.

Spatial maps leak facility intelligence

Spatial mapping creates a persistent representation of physical spaces. In sensitive environments, that map can reveal layouts, equipment placement, safety routes, and operational patterns. Treat “spatial understanding” like a form of digital twin data with its own classification.

Biometric and behavioral identification from gaze and motion

XR produces signals that are hard to think about like “personal data,” but are very identifying in practice.

Research has shown that eye movements can enable biometric identification even when you are not trying to identify someone.

Other work shows that combinations of eye tracking, headset tracking, and controller motion can be used to identify users, and that one signal can sometimes be used to work around protections applied to another.

In enterprise terms: “we only store tracking telemetry, not names” is not a get-out-of-privacy-free card.

Application-layer abuse: malicious apps and deceptive XR interfaces

XR apps can create convincing overlays and prompts that feel “system-like.” That can enable phishing-style attacks or UI manipulation, especially in browser-based XR. Security work on WebXR has explored the need for logging and defenses against interaction attacks in immersive environments.

Shared-device leakage and weak session boundaries

Many deployments share headsets across shifts. Risks include:

• cached accounts and tokens
• residual photos, spatial data, or app data
• “last user” permissions still active
• poor hygiene in kiosk modes

Supply-chain and cloud pathways

XR ecosystems often involve vendor services for device enrollment, app distribution, collaboration, analytics, and updates. Each service is a dependency and a potential exfiltration path. Enterprise documentation for devices like HoloLens and Vision Pro explicitly frames privacy and data protection as design considerations, but you still need to validate configurations and flows in your environment.

Mitigation: make XR boring through layered controls

Layer 1: Governance that matches sensor reality

Start with rules that acknowledge “sensors on”:

• Zone design: define where XR is allowed, restricted, and banned (think labs, HR areas, customer zones).
• Signage and consent: bystanders should know when spatial sensing is in use, especially in public-facing areas.
• Recording policy: distinguish between explicit recording and implicit capture via collaboration tools.
• Data classification: classify spatial maps, captured media, and telemetry. Apply retention limits.

Use a privacy risk method, not vibes. The NIST Privacy Framework and the NIST Privacy Risk Assessment Methodology (PRAM) are practical tools for identifying and prioritizing privacy risks tied to data processing and system design.

Layer 2: Enterprise device management and baseline hardening

Treat headsets like managed endpoints:

• enroll devices in a mobile device management (MDM) or unified endpoint management (UEM) solution
• enforce device encryption, strong unlock, auto-lock, and remote wipe
• block sideloading (unless you have a signed internal pipeline)
• keep firmware and operating systems patched
• restrict developer and research modes in production environments (these can expose additional sensor streams)

As an example of what “baseline hardening” looks like in practice, Microsoft publishes security baseline settings for HoloLens 2 via Intune.

Layer 3: Identity, access, and network controls (Zero Trust applied to XR)

XR is often used in motion and across networks. Assume devices will move and networks will change.

• integrate with enterprise identity (Single Sign-On (SSO), Multi-Factor Authentication (MFA))
• use conditional access policies (device compliance, location, risk signals)
• apply least privilege to apps and services
• segment network access for XR workloads

Layer 4: App governance and permission discipline

Most XR breaches will arrive through apps, not through exotic headset hacking.

• run an allowlist model for production deployments
• require signed builds and controlled distribution for internal apps
• review sensor permissions and data flows during security review
• for web-based XR, enforce browser policies and permissions consistent with W3C’s “powerful features” model (the WebXR spec is explicit that user agents must mitigate privacy and security risks).

Layer 5: Data minimization and privacy engineering

This is where “privacy” becomes engineering, not policy.

• prefer on-device processing over sending raw streams to the cloud
• store derived features (for example, task completion metrics) instead of raw gaze traces or video
• reduce precision and retention (short-lived spatial maps, clipped logs)
• separate identity from telemetry where possible, and assume re-identification risk for motion and gaze signals

Apple’s visionOS documentation emphasizes system-handled camera and sensor inputs and privacy best practices for developers, which aligns with the principle that apps should not receive more raw sensor data than necessary.

Closing thought

XR security is not “harder than everything else.” It is just different: more sensors, more inference, more human context.

The organizations that succeed are the ones that stop arguing about whether XR is “a camera” and start managing it like what it is: a roaming, always-sensing endpoint that needs strong governance, tight software control, and ruthless data minimization.