XR and Metaverse Security Guide: Privacy, Identity and Device Risks

Extended reality headsets are the most sensor-dense computers most organisations will ever deploy, and they capture body, eye and room data that can identify a person and reveal things about them that no laptop ever could. Virtual, augmented and mixed reality (together, XR) and the shared virtual spaces often called the metaverse are moving from pilots into training, design review, field service and remote collaboration. This guide covers what makes XR different from other endpoints, the privacy and inference risks of motion and gaze data, device and platform threats, identity and avatar trust, enterprise management and lifecycle, and the regulation that applies. It is written for security architects, endpoint and mobility teams, and privacy engineers who are asked to approve or run an XR deployment.

Key takeaways

• Motion data is identity data. Researchers identified a user among more than 50,000 with 94.33% accuracy from 100 seconds of head and hand motion, so telemetry that looks anonymous rarely is.
• The headset owns the user's perception. A malicious app that impersonates the home environment can record and alter what a user sees and does, which turns user interface integrity into a security control.
• Treat headsets as managed mobile endpoints. Enrol them in device management, restrict sideloading and developer mode, and apply the same patch and inventory discipline as phones.
• Plan for platform exits. Enterprise XR programmes have short and changeable vendor lifecycles, so record end of sale and end of security update dates for every model you buy.
• Run a privacy impact assessment before rollout. Gaze, biometrics, room scans and bystander capture can bring GDPR special category rules, biometric privacy laws and the EU AI Act ban on workplace emotion recognition into scope.

What makes XR different from other endpoints

An XR headset is, at its core, a mobile operating system with an unusual set of sensors. Several XR platforms are built on Android or on the same software stacks as phones and tablets, and the threats from the Mobile Device Security Guide apply. What changes is the data the device sees and the degree to which it controls what the user perceives. The European Data Protection Supervisor notes that XR systems can sample movement up to 1,000 times per second and may add gaze, heart rate or other physiological signals, which is difficult to reconcile with data minimisation and purpose limitation.

The practical consequence is that controls designed for laptops, which care about files and network traffic, miss the most sensitive data. A headset that never stores a document can still scan the whiteboard in a design review, record the room layout of a plant, and produce a behavioural fingerprint of the person wearing it.

Data and inference risks

Inference is the risk that most XR assessments underestimate. The USENIX Security 2023 paper by Nair and colleagues, "Unique Identification of 50,000+ Virtual Reality Users from Head and Hand Motion Data", used data from 55,541 real users and reached 94.33% identification accuracy from 100 seconds of motion and 73.20% from 10 seconds. Motion telemetry shared with an analytics provider or a multiplayer server should therefore be treated as personal data that can single out an individual, not as anonymous usage statistics.

• Behavioural fingerprinting: movement patterns are stable enough to link sessions across apps and accounts, which undermines pseudonymous accounts and makes "we only store device IDs" claims weak.
• Health and characteristic inference: EDPS points out that distance from the floor reveals height and that some authors associate head movement with neurological conditions. Inferred health data can fall under GDPR Article 9 even when nobody intended to collect it.
• Gaze as an intent signal: where a person looks before they choose is more revealing than what they choose. Apple's Vision Pro privacy overview states that where the user looks is not shared with apps or Apple until the user selects something by looking and tapping their fingers, and that hover highlighting is rendered by the system rather than the app. That design is a useful benchmark when you evaluate any platform: ask whether raw gaze reaches third party code.
• Room and bystander data: scene meshes and passthrough video capture colleagues, visitors and the contents of screens. In the same overview, Apple states that apps in the shared space cannot access surroundings data and that full space apps can do so only with permission and within five metres of the user. Other platforms make different choices, so check per app permissions rather than assuming.
• Emotional and immersive disclosure: EDPS also notes that immersion can lead users to share information they otherwise would not, which matters for social engineering inside virtual spaces.

For the wider treatment of these issues see the Privacy by Design Guide and the Biometrics Guide.

Device and platform threats

Most XR attacks are mobile attacks with a perceptual twist. The research paper "Inception Attacks: Immersive Hijacking in Virtual Reality Systems" (Yang, Li, Bhalla, Zhao and Zheng, 2024) showed on Meta Quest headsets that a malicious app posing as the full VR interface could trap a user, record and alter their interactions with apps, services and other users, and present two users in the same session with different experiences. The lesson is that an attacker who controls rendering controls what the user believes, including which login screen or which colleague they think they are talking to.

• Developer mode and sideloading: these are the most common route for untrusted code onto headsets. Treat them like disabling app store enforcement on a phone and allow them only on named development devices.
• Companion apps and accounts: many headsets are set up through a phone app and a consumer cloud account. That account becomes a control plane for the device: it can install apps, read activity and reset settings. Protect it with strong MFA and keep it organisation owned for corporate devices.
• Cross platform runtimes: OpenXR, the royalty free Khronos standard (currently version 1.1), lets the same application run on many devices. That is good for portability, but it means a vulnerability in a shared runtime or engine plug-in affects several platforms at once, so track third party components in your software bill of materials.
• Shared and kiosk devices: training headsets are often passed between staff. Without a guest or kiosk mode, the previous user's sessions, recordings and tokens remain on the device.

Identity, authentication and avatar trust

XR raises two identity questions: how the user proves who they are to the headset and to services, and how other people know an avatar is who it claims to be.

• Device unlock: typing passwords in a headset is slow and easy to shoulder surf through hand tracking, so platforms are moving to biometrics. Apple documents that Optic ID has a less than 1 in 1,000,000 chance of a random person unlocking the device (higher if only one eye is enrolled), that iris data is processed and stored encrypted in the Secure Enclave, never leaves the device and is not backed up, and that apps receive only success or failure. A passcode is required after five unsuccessful attempts, after restart and when the device has not been unlocked for more than 48 hours. Use these properties as the bar for any headset biometric: on device matching, hardware protected templates, no template export.
• Service sign-in: use device code flows or companion phone approval with passkeys rather than typed passwords inside the headset. See the Phishing-Resistant MFA Guide. Inception style attacks make a fake in-headset login screen realistic, so push authentication to a channel the attacker does not render.
• Enrolment single sign-on: Apple's deployment documentation lists Enrollment SSO for iPhone, iPad and Apple Vision Pro, which lets a managed headset join the identity provider rather than a personal account.
• Avatar and persona impersonation: a photorealistic avatar is synthetic media by design. In virtual meetings, verify high risk requests (payments, access grants, credential resets) through a separate channel exactly as you would for a video call. The Arup deepfake fraud shows how convincing a fake participant can be when nobody checks out of band. See the Deepfake and AI Impersonation Guide.
• Device identity: headsets also hold non-human credentials: MDM certificates, Wi-Fi certificates and app tokens. Inventory them and revoke them at retirement. See the Device and IoT Identity Guide.

Enterprise deployment, management and lifecycle

Decide early whether headsets are consumer devices tolerated on the network or managed corporate endpoints. The choice drives almost every other control.

Lifecycle risk is real. Microsoft states that HoloLens devices have not been manufactured since December 2024, that the November 2024 update was the last feature release and that monthly security servicing continues through December 2027, with a UK PSTI minimum security update period ending 28 February 2028 for units purchased until 28 February 2025. Meta announced that it would stop selling Horizon managed services and commercial Quest SKUs on 20 February 2026, keeping support for existing customers until 4 January 2030 and making licences available at no cost. Record these dates in your asset register, and do not buy fleets without a written security update commitment. Small organisations with a handful of headsets can manage them through the platform's own console in kiosk mode; large fleets should require integration with the existing MDM, identity provider and SIEM before purchase.

Privacy and regulation

• GDPR: biometric data processed to uniquely identify a person and health data, including inferred health data, are special category data under Article 9. Large scale processing of gaze or motion data will usually require a data protection impact assessment under Article 35. See the Employee Monitoring and Privacy Guide when headsets are used to measure staff.
• EU AI Act: Article 5(1)(f) prohibits AI systems that infer emotions of people in the workplace and in education, except for medical or safety reasons, and has applied since 2 February 2025. Any XR training analytics that score engagement or emotional state from gaze, voice or physiology need a legal review against it.
• Biometric privacy laws: where face geometry or iris templates are collected, laws such as Illinois BIPA require notice and written consent. See the Illinois BIPA and Biometric Privacy Guide.
• Product security law: the UK PSTI regime applies to consumer connectable products, which is why Microsoft publishes a PSTI update period for HoloLens 2. Ask suppliers for their declared support period.
• Children: consumer metaverse platforms used by under 18s bring children's privacy codes and COPPA into scope. See the COPPA and Children's Privacy Guide.

How to implement an XR security programme

1. Inventory and classify use cases. List every headset, model, owner, account type and use case. Classify by the most sensitive thing the cameras can see, not by the app's data.
2. Run a privacy impact assessment. Map sensor streams to purposes, identify special category and inferred data, decide what may leave the device, and record retention for recordings and scene meshes.
3. Pilot in a managed ring. Enrol 5 to 10 devices in MDM with sideloading and developer mode off, casting and recording restricted, and kiosk or guest mode for shared use. Measure user friction and break-glass needs for two to four weeks.
4. Integrate identity and network. Connect enrolment to the identity provider, issue device certificates for Wi-Fi, place headsets on a segmented network and build an egress allow-list from observed vendor domains.
5. Roll out by site risk. Start with training rooms, then offices, then secure or regulated areas, where cameras may need to be disabled by location or the devices excluded entirely.
6. Define rollback. Keep a documented path to unenrol a device, wipe it and return it to the vendor default, and keep the previous policy version so a breaking restriction can be reverted from the console within one change window.
7. Plan retirement. At end of support or end of life, revoke certificates and tokens, wipe, and remove the device from the platform tenant.

Detection and measurement

Headsets produce limited security telemetry, so most detection comes from the management console, the identity provider and the network. Monitor MDM compliance state and policy changes, installs outside the managed catalogue, developer mode toggles, companion account sign-ins and recovery events, and egress to domains outside the allow-list.

• Enrolment coverage: percentage of headsets enrolled in MDM (target 100% for corporate owned).
• Patch latency: median days from vendor security update to installation across the fleet.
• Unmanaged app rate: number of devices with apps outside the approved catalogue, per month.
• Support horizon: percentage of fleet with more than 12 months of committed security updates remaining.
• Privacy review coverage: percentage of XR use cases with a completed impact assessment before production use.

Framework mapping

Common failure patterns

• Consumer accounts on corporate headsets: devices registered to an employee's personal account leave the organisation unable to wipe, audit or recover them when the person leaves.
• Developer mode left on after a pilot: the setting that made the proof of concept easy becomes the route for unvetted apps in production.
• Treating motion telemetry as anonymous: sharing raw tracking data with analytics vendors without a contract or DPIA, despite evidence that it identifies people.
• Headsets in secure areas: passthrough cameras and scene meshes capture whiteboards, screens and floor plans in rooms where phones are banned.
• Buying into a platform without a lifecycle commitment: fleets left without security updates or management service after an enterprise programme ends.
• Trusting the face on the avatar: approving payments or access changes in a virtual meeting without out of band verification.

Practitioner checklist

• Maintain an inventory of every headset with model, owner, account type, use case and end of security update date.
• Enrol corporate headsets in MDM using organisation owned accounts and enrolment SSO where supported.
• Disable developer mode, sideloading, casting and screen recording except on named devices.
• Use kiosk or guest mode on shared training headsets and clear sessions between users.
• Complete a privacy impact assessment covering gaze, motion, biometrics, room scans and bystanders.
• Check any engagement or emotion analytics against EU AI Act Article 5(1)(f) before use.
• Segment headsets on the network with an egress allow-list and certificate based Wi-Fi.
• Require out of band verification for high risk requests made in virtual meetings.
• Track the five KPIs above and review lifecycle dates at least twice a year.

Standards and references

• EDPS: TechSonar, Extended Reality
• USENIX Security 2023: Unique Identification of 50,000+ Virtual Reality Users from Head and Hand Motion Data
• arXiv: Inception Attacks, Immersive Hijacking in Virtual Reality Systems
• Apple: Apple Vision Pro Privacy Overview
• Apple: About Optic ID advanced technology
• Microsoft Learn: HoloLens 2 release notes
• Khronos Group: OpenXR
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Wearables Security Guide · Mobile Device Management Security Guide · IoT Security Guide · On-Device AI Security Guide