How a VR Headset Is Made: Displays, Lenses, Tracking, Firmware, Eye Data

A VR headset is made by mounting two small, fast displays behind lenses, adding outward tracking cameras, inertial sensors and inward infrared eye cameras, and wiring them to a system on chip running an Android based or proprietary OS and an OpenXR runtime. Its sensors collect very personal data: room maps, hand shapes and where your eyes look.

This post goes one level deeper than our builds of a smartwatch and a game console. For the panels themselves, read how OLED and LCD displays are made; for the tracking cameras, how camera image sensors are made. Mapping a room with cameras is close cousin to what a robot vacuum does with lidar and SLAM.

Key takeaways

• A headset is eight subsystems sharing one tight power and weight budget.
• Two display families dominate: fast switching LCD with a backlight, and micro OLED built on a silicon wafer.
• Pancake lenses fold the light path so the display can sit closer to the lens and the headset gets thinner.
• Inside out tracking fuses camera images with inertial measurement units (IMUs), often on a dedicated chip to keep latency low.
• Eye tracking shines invisible infrared light on each eye and films the reflections. Apple says where you look is not shared with apps before you select something; Meta's developer docs treat "abstracted gaze data" as user data behind a runtime permission.
• The software stack is largely open source underneath: Meta says Horizon OS began on AOSP, and Monado is an open source OpenXR runtime.
• Updates matter more than on most gadgets because the sensors are always on. Apple's security releases page says visionOS cannot be downgraded after an update is installed.
• Safeguard's fit is indirect: it scans the XR apps, companion apps and back ends your team builds, not the headset.

What are the main subsystems of a VR headset?

Every standalone headset solves the same problem: draw a stereo image fast enough, with low enough delay, that the brain accepts it as a place, in an enclosure light enough to wear for an hour.

Why the subsystems fight each other

Weight is the constraint everything else bends around. iFixit's February 2024 teardown put the Vision Pro's front assembly at 532 grams without its battery, close to the 522 grams it found for the Quest Pro's equivalent, and noted that Apple moved the battery into a 353 gram pocket pack. Every extra camera adds weight, power and heat on the face, and higher resolution pushes the SoC harder. Eye tracking exists partly to break that loop, as the foveated rendering section explains.

How are the displays made and chosen?

A headset display sits a few centimetres from the eye behind a magnifying lens, so it has to do three things phone screens do not: pack pixels far more densely, switch from one frame to the next very quickly, and avoid smearing when the head turns. Two families of panel meet those needs in different ways.

Fast switching LCD

A liquid crystal display does not make light. A backlight shines through a layer of liquid crystal that twists to let more or less light through each subpixel, and colour filters split it into red, green and blue. Headset LCDs use liquid crystal modes that switch quickly, and many drive the backlight in short pulses so that each frame is shown only briefly. That low persistence reduces the smear you would otherwise see when the image is held on screen while your head moves.

Headset LCDs are made on glass like larger panels: a thin film transistor array on one substrate, a colour filter plate on another, liquid crystal sealed between them, then polarisers and a backlight. Our OLED and LCD manufacturing post covers those steps.

Micro OLED on silicon

A micro OLED makes light in each pixel, like a phone OLED, but it is built on a silicon wafer rather than on glass. The pixel driving circuits live in a CMOS backplane made in a semiconductor fab, so the transistors can be far smaller than thin film transistors on glass, and the pixel pitch can shrink to a few microns. Organic light emitting layers are deposited on top of the backplane, sealed against moisture and oxygen, and colour is commonly produced with colour filters over the emitters. The wafer is then cut into individual displays, much as image sensor wafers are diced.

Apple's current Vision Pro technical specifications describe exactly this category: a "3D display system" using micro OLED with a 7.5 micron pixel pitch, 23 million pixels and 92 percent of the DCI P3 colour gamut. The same page lists supported refresh rates of 90, 96, 100 and 120 Hz and says the headset plays video at multiples of 24 and 30 frames per second so that film content does not judder.

Worked example 1: how small is a 7.5 micron pixel grid?

Apple gives 23 million pixels for the whole display system. Split evenly across two eyes, that is 11.5 million pixels per eye.

To get a feel for the physical size, imagine those pixels arranged in a square. The square root of 11,500,000 is about 3,391, so the square would be about 3,391 pixels on each side. At 7.5 microns per pixel, 3,391 pixels span 3,391 multiplied by 0.0075 mm, which is about 25.4 mm.

So each eye's image would fit on a patch of silicon about an inch across. The real panels are not square and the numbers are illustrative, but the scale explains why micro OLED is made in a chip fab rather than on sheets of glass.

Worked example 2: frame time at each refresh rate

Refresh rate sets how long the renderer has to produce each frame.

At 120 Hz the whole pipeline, from reading the latest head pose, through rendering two views, to scanning them out to the displays, has about 8.3 ms per frame. That budget is why headsets reproject frames, render the periphery at lower resolution and push sensor processing onto dedicated hardware.

Display comparison

How are the lenses made and chosen?

The lens decides how large the virtual image looks, where your eye has to be for it to stay sharp, and how thick the front of the headset ends up. Two designs dominate.

Fresnel lenses

A Fresnel lens takes a thick curved lens and collapses its curvature into a series of concentric ridges on a thin plate. It focuses light like the thick lens it replaces, but weighs a fraction as much, and it can be moulded cheaply from optical plastic. The cost is that the ridges scatter some light, which shows up as glare or "god rays" around bright objects on a dark background. Because a single Fresnel lens bends light once, the display has to sit roughly a focal length behind it, which sets the depth of the headset.

Pancake lenses

A pancake lens folds the light path. The light from the display passes through the lens stack, is reflected back by a partly reflective layer, and then forward again before it reaches the eye. Polarising films and a wave plate control which bounce is allowed through, so the path between display and eye is longer than the physical gap. The display can therefore sit much closer to the lens, which makes the front of the headset thinner and moves weight towards the face.

Meta's Quest Pro announcement on 11 October 2022 said its pancake lenses "fold light over several times," reducing the headset's size while showing sharper visuals. The price is light loss: each pass through a partial mirror or polariser throws light away, so pancake optics need brighter displays.

How lenses are made

Headset lenses are usually moulded from optical plastic or ground from glass. A pancake stack adds laminated films, such as a reflective polariser and a quarter wave plate, plus partial mirror and anti reflection coatings. The finished module is aligned to the panel, because a tiny tilt shows up as blur at the edge of the view.

IPD adjustment and prescription inserts

Interpupillary distance (IPD) is the distance between the centres of your pupils. If the lens centres do not line up with your eyes, the image blurs and stereo depth feels wrong. Headsets handle this in one of three ways: fixed lens positions with a large sweet spot, a manual slider that moves the lenses, or motors that move the lenses automatically after measuring your eyes.

Apple's spec sheet lists an IPD range of 51 to 75 mm. iFixit's teardown describes motors adjusting the lens positions when you first put the headset on, and notes that the optional prescription inserts must be "paired" with the headset during setup so that eye tracking can be calibrated with the extra lens in place.

Lens comparison

How does inside out tracking work?

Tracking answers one question many hundreds of times a second: where is the head, and which way is it pointing? Early consumer headsets answered it from the outside, with fixed cameras or base stations in the room looking at the headset. Most standalone headsets now answer it from the inside, with cameras on the headset looking at the room. Meta's April 2024 Horizon OS announcement lists inside out tracking and self tracked controllers among the technologies it developed to make standalone headsets possible.

Cameras plus IMU, fused

Inside out tracking combines two kinds of sensor that fail in opposite ways.

• An IMU (an accelerometer and gyroscope, sometimes with a magnetometer) reports rotation and acceleration hundreds or thousands of times a second with very little delay. But integrating those readings to get position drifts quickly: small errors add up.
• Cameras see fixed features in the room, such as corners, edges and textured surfaces. Comparing where those features appear across frames, and across two or more cameras, gives absolute position and orientation without drift. But cameras run at lower rates, need processing, and struggle in the dark or in front of blank walls.

The tracking system fuses the two. The IMU carries the pose between camera frames, and each camera frame corrects the IMU's drift. At the same time the system builds a map of the features it has seen, which is the "mapping" half of SLAM (simultaneous localisation and mapping). That map is what lets the headset recognise a room it has seen before and restore your play area.

Apple's spec sheet lists the Vision Pro's sensor set as two main cameras, six world facing tracking cameras, four eye tracking cameras, a TrueDepth camera, a LiDAR scanner, four IMUs, a flicker sensor and an ambient light sensor. iFixit's teardown describes the R1 chip as "specifically responsible" for processing input from the cameras, the LiDAR sensor and the TrueDepth camera with minimal latency, and Apple's spec sheet gives the R1's figure as 12 millisecond photon to photon latency. Putting sensor fusion on a dedicated chip keeps the most time critical work off the busy application processor.

Worked example 3: why a few milliseconds matter

Suppose you turn your head at 200 degrees per second, a brisk but ordinary glance to the side. During any delay between the head moving and the image updating, the world appears to drag with your head.

• At 12 ms of latency: 200 degrees per second multiplied by 0.012 seconds is 2.4 degrees of error.
• At 50 ms of latency: 200 multiplied by 0.05 is 10 degrees of error.

Ten degrees is roughly a fist's width at arm's length, the kind of mismatch between inner ear and eyes that makes people feel sick. The numbers are illustrative, but they show why latency is quoted in milliseconds.

Hand tracking and controllers

Hand tracking runs a model on the outward camera images to estimate each finger joint. Tracked controllers carry their own IMU and either infrared LEDs the headset cameras can see or cameras of their own, and each runs its own firmware.

Outside in tracking has not disappeared. The open source Monado runtime's developer site lists outside in tracking for PlayStation VR and Move controllers using stereo cameras such as the PS4 camera.

How does eye tracking work?

Eye tracking points small infrared cameras at each eye and lights the eye with infrared LEDs that the wearer cannot see. The LEDs create bright reflections (glints) on the cornea, and the camera also sees the dark pupil. Because the cornea is curved and the pupil moves with the eye, the geometry between pupil and glints changes in a predictable way as the eye rotates. A per user calibration fits that geometry to your particular eyes, and from then on the system can estimate a gaze direction for each eye, many times a second.

Apple's privacy overview describes the Vision Pro's version in plain terms: "an advanced and interconnected system of LEDs and infrared cameras" projects invisible light patterns onto each eye, and Eye Setup produces "a customized model of your individual eye geometry" that stays on the device, is encrypted, and is not shared with apps. The spec sheet lists four eye tracking cameras.

Meta's developer documentation describes eye tracking on the Quest Pro, which Meta's 2022 announcement called its first headset with inward facing sensors for facial expressions and eye tracking. The docs say the API is supported on Quest Pro but not on Quest 2 and older devices, which lack those sensors.

What foveated rendering is

The eye sees fine detail only in a small central region, the fovea. Everything further out is seen at much lower resolution. Foveated rendering exploits this: the headset renders full detail only where you are looking and progressively less towards the edges. With eye tracking the high detail region follows your gaze (dynamic foveation); without it, the headset can still reduce detail towards the edges of the lens (fixed foveation).

Apple's spec sheet hints at this when it says you can "record your view in 4K, unfoveated, for up to three minutes." A recording mode labelled unfoveated only makes sense if the normal view is foveated. The saving matters because of the frame time budget in worked example 2: rendering less detail where you are not looking frees time for what you are looking at.

Gaze as an input, and gaze as data

Eye tracking does two different jobs, and the standards reflect it. Khronos publishes the OpenXR extension XR_EXT_eye_gaze_interaction for using eye gaze as an input. Meta's documentation describes a separate extension, XR_FB_eye_tracking_social, for social uses such as making an avatar's eyes meet another person's. Meta notes that its social extension returns a confidence value that is currently fixed at 0.5 and that gaze from both eyes is temporally smoothed.

The privacy question is the difference between the two. If the OS highlights what you look at and tells the app only when you select it, the app learns your choice. If the app receives a continuous gaze stream, it learns what caught your attention. Apple's privacy overview puts it directly: "where you look can reveal what you are thinking."

Optic ID: iris recognition in the same hardware

The same inward cameras and LEDs can image the iris. Apple's privacy overview says Optic ID uses LEDs, infrared cameras and machine learning to create "a mathematical representation of your iris," which is encrypted and protected by the Secure Enclave, does not leave the device, and is never backed up to iCloud. Apps that use Optic ID learn only whether authentication succeeded. The spec sheet adds that Optic ID data is accessible only to the Secure Enclave processor. The Apple Platform Security guide covers Optic ID matching security alongside Face ID and Touch ID.

How is a VR headset made, step by step?

Headset makers do not publish their full factory process, so the table below describes the typical flow for the category and marks where a fetched vendor or teardown source documents a specific detail. Each stage is usually done by a different supplier, and the parts meet at final assembly.

Worked example 4: the battery pack numbers

iFixit reports that the Vision Pro battery pack holds three cells at about 3.8 volts each, wired in series, at 3,166 mAh each, and gives the pack voltage as 11.34 volts.

• In series, voltages add and capacity stays the same: about 3 multiplied by 3.8 V, or roughly 11.4 V, close to the 11.34 V iFixit gives.
• Energy is voltage multiplied by capacity: 11.34 V multiplied by 3.166 Ah is about 35.9 Wh, matching iFixit's total.

Apple's spec sheet gives up to 2.5 hours of general use. Dividing 35.9 Wh by 2.5 hours suggests an average draw of roughly 14 watts, an illustrative estimate rather than a measurement, and a reminder of why every subsystem is designed around power.

Why calibration is per unit

No two headsets are identical. Tracking depends on knowing exactly where each camera sits relative to the others and to the IMU, and the renderer pre distorts each frame to cancel that unit's lens distortion, so factories measure both on a rig and store per unit calibration files. That is also why replacing a camera or lens usually needs recalibration.

What software runs on a headset?

A standalone headset is a full computer, and its software stack looks like a phone's with extra layers for tracking and rendering.

Operating system

• Android based. Meta says Horizon OS, the operating system on Quest headsets, is the result of work that "began on the mobile-first foundations of the Android Open Source Project." In April 2024 Meta announced it would open Horizon OS to other device makers and named ASUS's Republic of Gamers and Lenovo as building headsets on it. Developers request access to sensitive features through Android style runtime permissions, which the next sections cover.
• Proprietary. Apple's Vision Pro runs visionOS. Apple's security releases page lists visionOS updates alongside iOS and macOS, including visionOS 27 on 14 September 2026 and visionOS 27.0.1 on 28 September 2026, the latest version at the time of writing.

The OpenXR runtime

OpenXR is Khronos's royalty free open standard API for virtual and augmented reality. Khronos ratified OpenXR 1.0 on 29 July 2019 at SIGGRAPH and released OpenXR 1.1 on 15 April 2024, which folded widely used extensions into the core specification to reduce fragmentation.

An application written to OpenXR talks to the OpenXR loader, and the loader finds the active runtime, the vendor or open source code that actually drives the headset. On Linux the OpenXR loader specification says the loader looks for a file named active_runtime.<arch>.json and then active_runtime.json in XDG configuration directories, for example /etc/xdg/openxr/1/active_runtime.x86_64.json, and that the XR_RUNTIME_JSON environment variable overrides the search. That small JSON file decides which shared library every XR application loads, so it deserves the same care as any other piece of configuration that chooses code.

Monado is an open source OpenXR runtime. Its developer site says it aims to be a complete and conformant implementation of OpenXR, is developed for GNU/Linux, Android and Windows, is officially conformant, and supports Vulkan, OpenGL and OpenGL ES, plus Direct3D 11 and 12 on Windows. Monado's selling point for developers is that you can inspect and debug the entire stack, from your application down to the headset driver. For security teams it is also a reminder that an XR runtime is a dependency with its own release history, like any other.

Firmware beyond the main OS

A headset carries several firmware images besides the operating system:

• boot ROM and bootloader on the SoC;
• firmware for the sensor hub or co processor that handles cameras and IMUs;
• display driver IC firmware and calibration tables;
• Wi Fi and Bluetooth radio firmware;
• controller firmware, which is updated over Bluetooth from the headset;
• battery management firmware.

Each one is a place where a bug can sit, and each one has to be updated through some signed path.

How are updates signed and delivered?

The fetched vendor documents describe the end user view of updates more than the cryptography, so here is what can be confirmed and what cannot.

• Apple. Apple's security releases page says that once an update is installed for visionOS (and iOS, iPadOS, tvOS and watchOS), "it cannot be downgraded to the previous version." The Apple Platform Security guide documents secure boot and the Secure Enclave.
• Android based headsets. The Android Open Source Project documents Android Verified Boot, which checks each stage of the boot chain against signed metadata and includes rollback protection, and A/B system updates, which write the new system to an inactive slot and switch to it on reboot. Our Android Verified Boot explainer covers the chain of trust. Whether a given Android based headset uses every one of these features, and how its vendor signs controller and camera firmware, is not something we could confirm from the vendor's public pages; check the vendor's own security documentation for your model.
• Controllers. Controller firmware is typically pushed from the headset when the controller is paired and connected. If you leave controllers in a drawer, they may miss updates until you next pair them.

What data does a headset collect?

Headsets are built around cameras and sensors that are on whenever the device is in use. That makes the data question unusually concrete.

Surroundings and room maps

Apple's privacy overview says visionOS builds a three dimensional model of your surroundings on device from camera and LiDAR data, uses it to warn you about obstacles and to match lighting, and stores the underlying scene mesh on device, encrypted with your passcode if one is set. Apps in the default Shared Space cannot access surroundings data. Apps in a Full Space can ask permission, and even then receive only information within five metres of where you are.

Meta's developer documentation describes a spatial data runtime permission, com.oculus.permission.USE_SCENE, that controls which apps can access a user's spatial data on Quest 2, Quest Pro and Quest 3. Apps that want the Scene API must request it at runtime, and only after the user grants it can the app query spatial data on the device.

Eye tracking data

Apple says visionOS processes eye movements at the system level and does not share where you look with apps or websites before you select something. Hover effects that respond to your gaze are rendered by visionOS out of process, so the app does not know what you are looking at until you tap your fingers together.

Meta's eye tracking developer docs take a different model: an app can receive "real time abstracted gaze data" once the user enables eye tracking for that app. The app must declare com.oculus.permission.EYE_TRACKING, which is a runtime permission the user has to grant; it must post a privacy policy explaining its collection and use of the data; it must obtain the user's consent before collection; and the data counts as user data under Meta's Developer Data Use Policy. Meta also reserves the right to monitor use of the API.

Hands, head, voice and identity

Apple's overview says hand size and shape data from setup is stored on device, and immersive apps must ask permission for hand structure and movement, which includes finger joints, wrists and elbows. Shared Space apps cannot read head orientation. Persona is generated on device from photos stored encrypted there, and Guest User sessions delete the guest's eye and hand setup when they end.

Data table

Two cautions. The table reflects only the vendor documents we could fetch; Meta's consumer eye tracking privacy notice did not render for scripted clients, so we have not summarised its retention terms. Read it in Meta's help centre or headset settings. And "on device" describes where the vendor processes raw sensor data; once you grant an app a permission, the app's own privacy policy governs what it keeps.

Dated timeline

Apple's current spec sheet lists an M5 chip; the February 2024 privacy overview names the M2 in the original model.

Step by step: check and tighten a headset and the apps around it

The steps below suit two audiences: owners or IT teams who manage headsets, and developers who ship XR apps or companion services. Every command is read only or reversible; none of them wipes a device.

1. Turn on developer access only when you need it

On Android based headsets, adb (Android Debug Bridge) needs developer options and USB debugging turned on. Android's adb documentation says a paired device stays authorised until you explicitly forget it or revoke adb debugging authorisations on the device. Do that when you finish.

# Confirm which devices this workstation can reach
adb devices -l

If you see a headset you did not expect, revoke USB debugging authorisations in the headset's developer settings before doing anything else.

2. Record the build you are running

# Standard Android build properties; exact values vary by vendor
adb shell getprop ro.build.fingerprint
adb shell getprop ro.build.version.security_patch

Record it with the serial number so you can match headsets to vendor bulletins later.

3. See which apps hold eye tracking and spatial data permissions

Meta's docs name the permissions: com.oculus.permission.EYE_TRACKING for eye tracking and com.oculus.permission.USE_SCENE for spatial data. Check an app's grants from the package manager dump.

# Replace com.example.xrapp with the package you are checking
adb shell dumpsys package com.example.xrapp | grep -E "EYE_TRACKING|USE_SCENE|RECORD_AUDIO|CAMERA"

Look for granted=true next to each permission.

4. Revoke a permission you did not mean to grant

Android's adb documentation lists pm revoke for removing a permission declared in an app's manifest on Android 6.0 and later.

adb shell pm revoke com.example.xrapp com.oculus.permission.EYE_TRACKING

The app will ask again next time, and you can refuse.

5. For PC VR on Linux, confirm which OpenXR runtime is active

# User level choice wins over system level, per the OpenXR loader spec
ls -l "${XDG_CONFIG_HOME:-$HOME/.config}/openxr/1/" 2>/dev/null
ls -l /etc/xdg/openxr/1/ 2>/dev/null
cat /etc/xdg/openxr/1/active_runtime.json 2>/dev/null
echo "XR_RUNTIME_JSON=${XR_RUNTIME_JSON:-unset}"

The JSON names the library every OpenXR app loads. Make sure it points at a runtime you trust and is not writable by other users.

6. In your app, ask for sensitive permissions only when needed

Meta's spatial data documentation follows Android's guidance: request the permission when the feature is used and provide a fallback if the user declines. Check what your manifest declares before each release.

grep -n "uses-permission" app/src/main/AndroidManifest.xml

If EYE_TRACKING appears, confirm the privacy policy and in app consent that Meta's docs require are in place and accurate.

7. Produce an SBOM for the app and its services

CISA's 2026 Minimum Elements for an SBOM replaced the 2021 NTIA list on 29 July 2026. CycloneDX is one standard SBOM format. Generate an SBOM from each build of an XR app or companion service and scan it with the repository.

# Scan the repository and its lockfiles
safeguard scan --dir .

# Scan an SBOM produced by your build
safeguard scan --sbom build/sbom.cdx.json

# Scan the container image for a companion back end
safeguard scan --image registry.example.com/xr-sync:1.4.2

Results land as JSON under ./output, which you can archive with the release.

8. Gate releases on what you find

In Safeguard, a policy gate evaluates findings in CI with one of three actions: Block, Warn or Notify. A team that must ship despite a finding requests an exception, so approval happens without weakening the gate. A sensible start is Block on known exploited vulnerabilities and Warn on the rest.

Common mistakes

• Sideloading unknown apps. An app from outside the store skips review, yet once granted permissions reads the same sensors as any other app.
• Tapping through eye tracking prompts. Grant eye tracking only to apps that need gaze, and revoke it when you stop using them.
• Leaving developer mode on. With USB debugging on and old workstations still authorised, more people can install software or read data.
• Never updating controllers. Controller firmware arrives through the headset, so spares kept in a drawer sit on old firmware.
• Skipping headset updates. Updates carry fixes for the OS, browser and radios. On visionOS you cannot go back after updating, which blocks rollback to a version with known bugs.
• Sharing a headset without guest mode. Apple's Guest User mode deletes a guest's eye and hand setup afterwards; use the equivalent on shared devices.
• Assuming "on device" means "never shared." An app you grant access to can store what it receives under its own policy.
• Trusting any OpenXR runtime file. On PC VR, whoever controls active_runtime.json controls which library loads into every XR app.

FAQ

How is a VR headset made?

Suppliers make the displays on glass or silicon wafers, mould and coat the lenses, and build camera modules, the main board and the battery. Final assembly joins them; the factory flashes signed firmware, calibrates each unit's cameras, IMUs, lenses and displays, then tests and packs it.

What is the difference between pancake and Fresnel lenses?

A Fresnel lens bends light once using concentric ridges, so the display sits about one focal length behind it. A pancake lens folds the light path with partial mirrors and polarising films, so the display can sit much closer, making the headset thinner. Pancake lenses lose more light, so they need brighter panels.

Is micro OLED better than LCD for VR?

Neither wins everywhere. Micro OLED offers very fine pitch and true blacks but costs more per square millimetre. Fast switching LCD is mature and cheaper at high resolution, but its backlight limits black levels.

How does inside out tracking work without base stations?

Headset cameras watch fixed features in the room while IMUs report motion between frames. Fusing both gives head position and orientation, and the system maps the room as it goes (SLAM).

Can apps see where I am looking in a VR headset?

It depends on the platform. Apple says visionOS does not share where you look with apps before you select something. Meta's docs let apps receive abstracted gaze data if you grant the eye tracking permission, and require those apps to explain their use and get your consent.

What operating system does a VR headset run?

Many standalone headsets run an Android based OS; Meta says Horizon OS began on the Android Open Source Project. Apple's Vision Pro runs visionOS. PC VR headsets rely on the PC's OS and an OpenXR runtime, which on Linux can be the open source Monado.

What is OpenXR?

A royalty free Khronos standard giving XR apps one API across headsets. Version 1.0 shipped in July 2019 and 1.1 in April 2024; a vendor or open source runtime does the device specific work.

Should I update my VR headset and controllers?

Yes. Updates fix security bugs in the OS, browser, radios and sensor firmware. Keep controllers paired so they receive firmware too.

Where Safeguard fits, honestly

Safeguard does not make, test or analyse headsets. It does not scan headset firmware images, verify bootloader signatures, generate hardware bills of materials, manage devices, or assess optics, displays or eye tracking accuracy, and its models are single purpose security models for software. The fit is narrower and real: the software around a headset is ordinary software. XR apps pull game engine plugins, OpenXR loaders and networking libraries; companion phone apps pull mobile SDKs; sync and multiplayer back ends pull web frameworks and container base images. Safeguard scans repositories, container images and SBOM files for components with known vulnerabilities, shows which projects carry a given component and version, ranks findings by reachability where it can (the effect depends on the codebase and should be measured during an evaluation), evaluates policy gates with Block, Warn or Notify actions and exceptions for approval, and can open fix pull requests when a fixed version exists, with autonomous remediation switched off by default.

An XR app or companion service rebuilds against its dependencies on every release, and the runtimes, engines and libraries underneath headsets are open source projects with their own advisories, so software supply chain hygiene decides whether a fix you need actually reaches the device on your face. The fit is indirect for the hardware and direct for the code your team builds and ships around it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fits the web dashboard or multiplayer back end that sits behind an XR app.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits XR teams who build on their own workstations with large engine projects and want repository and SBOM scans to run next to the toolchain rather than in someone else's cloud.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which Safeguard tools Claude can use. A developer working on a companion app could ask Claude which projects carry a vulnerable library version, with Claude limited to the tools that were allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Khronos Group, OpenXR overview
• Khronos Group, Khronos Releases OpenXR 1.0 Specification (29 July 2019)
• Khronos Group, Khronos Releases OpenXR 1.1 (15 April 2024)
• Khronos Group, OpenXR registry, XR_EXT_eye_gaze_interaction
• Khronos Group, OpenXR Loader specification
• Monado developer site
• Apple, Apple Vision Pro technical specifications
• Apple, Apple Vision Pro Privacy Overview (February 2024, PDF)
• Apple, Apple Platform Security guide
• Apple, Apple security releases
• iFixit, Vision Pro Teardown (3 February 2024)
• Meta, Meta Connect 2022: Meta Quest Pro (11 October 2022)
• Meta, Introducing Meta Horizon OS (22 April 2024)
• Meta for Developers, Eye Tracking in Movement SDK for OpenXR
• Meta for Developers, Spatial Data Permission
• Android Open Source Project, Security features
• Android Open Source Project, Verified Boot
• Android Open Source Project, A/B system updates
• Android Developers, Permissions on Android
• Android Developers, Android Debug Bridge (adb)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (29 July 2026)
• CycloneDX, Specification overview

Last reviewed: 25 October 2026.