Check smart glasses vendor security before purchase

Time needed about four hours, spread over two days

The steps

1. Request audit and pentest reportsEmail the vendor and ask for the most recent SOC 2 or ISO 27001 evidence, the full penetration‑test report with findings and remediation status, and signing certificate fingerprints for firmware and apps.You should see: You receive PDFs or secure links to reports that include scope, dates and technical findings, plus certificate fingerprints that can be checked against binaries.
2. Get the signed update and patch policyRequest a dated, signed update policy specifying patch timelines by severity, forced‑update capability for critical fixes, and rollback protection procedures.You should see: A signed policy document listing maximum timeframes for critical/high/medium patches and stating whether critical updates can be forced to devices.
3. Obtain data‑flow diagrams and retention rulesAsk the vendor for a network and data‑flow diagram covering device, companion apps, vendor cloud and third parties, plus a table of retention rules for raw streams and derived metadata.You should see: A diagram that labels raw versus processed data, shows processing locations, and a retention table with explicit durations and deletion procedures.
4. Perform the ten‑minute hands‑on testFactory‑reset the test device or create a new profile, exercise camera and microphone use, observe permission prompts and indicators, and monitor outbound connections from the companion phone while idle and while streaming.You should see: Runtime permission prompts appear; a visible LED or on‑screen indicator shows when camera/mic are active; outbound connections are visible and map to hosts listed in the vendor documentation.
5. Validate app provenance and controlsRequest a signed roster of approved apps with package names and publisher IDs, inspect installed packages on the device, and confirm whether IT can block or approve app installations centrally.You should see: A roster with package names that matches installed apps and a documented control path showing how apps are blocked or approved centrally.
6. Check incident response and VDPRequest the vendor's incident response plan, a written breach notification timeframe, and their VDP or bug‑bounty page; ask for a redacted example of a handled incident if available.You should see: A documented IR plan, a written breach notification timeframe, and a VDP link or policy with contact details.
7. Negotiate contract security clausesWork with legal to insert audit rights, a DPA, security SLAs for patching, breach notification timelines, and an indemnity clause tied to vendor negligence into the contract.You should see: A contract draft or amendment that includes the requested clauses or an agreed redline showing vendor acceptance.
8. Score vendors and decideEnter the documentary evidence and hands‑on results into your scoring template, weigh hard failures (missing pentest, no forced update, raw streams leaving device) as disqualifiers, and select the highest‑scoring vendor for a pilot.You should see: A ranked vendor list with documented reasons for disqualification or selection and a clear next action to run a pilot with audit conditions.

Check smart glasses vendor security

You are buying smart glasses for staff. Do not accept marketing claims alone. Require verifiable documents and hands‑on checks: third‑party audit or pentest reports, signed update policies, a data‑flow diagram that reveals whether raw camera or microphone streams leave the device, and contract clauses granting audit and breach rights.

Demand verifiable third‑party evidence

Ask for full audit and penetration‑test reports and cryptographic proof of signing, not summaries. The full documents let you confirm scope (device backend, companion apps, cloud), see technical findings, and verify that fixes were validated by the tester.

• Audit report: request the full report or an auditor letter that states scope and date so you can confirm device backends and apps were tested.
• Penetration test: request the technical report with findings, remediation status, and whether fixes were re‑tested.
• Cryptography proof: request signing certificate fingerprints for firmware and apps and match them to the binaries you install.

Require secure software lifecycle guarantees

Get a signed update policy that specifies maximum patch timelines by severity, a forced‑update capability for critical fixes, and rollback protections. Unsigned or vague promises are meaningless; require sample update logs so you can confirm the vendor follows the process in practice.

• Patch timelines: clear maximum time to produce and distribute fixes for critical, high and medium vulnerabilities.
• Forced update: vendor must be able to push critical updates and prevent use of unpatched devices.
• Signing and rollback protections: how firmware and app images are signed and how the device blocks downgrade attacks.
• Sample update logs: records of prior security patch deployments to verify practice matches policy.

Prove the data flow and retention rules

Require an architecture diagram that shows every hop for camera and microphone data and explicitly states whether raw video or audio leaves the device. The diagram must label raw versus processed data, show where processing occurs, provide retention durations per data type, and describe encryption and key management.

• Explicit labels: raw versus processed data and the physical location of each processing step (edge, companion phone, vendor cloud, third party).
• Retention rules: exact retention durations and deletion procedures for raw streams, extracted metadata and logs.
• Encryption and keys: state TLS usage and where keys live, and whether keys are vendor‑managed or under customer control.

Operational security and incident response

Require a documented incident response plan, a vulnerability disclosure program (VDP) or bug‑bounty, and contractual breach notification timelines. Confirm how the vendor preserves device and cloud logs for forensics and whether they will provide controlled access or escrow keys under legal controls.

• Vulnerability disclosure: VDP page or policy and whether the vendor pays or simply responds ad hoc.
• Breach notification: a written timeframe for notification from confirmation to customer notice.
• Forensics access: documented process for preserving logs and whether the vendor will provide limited forensic access or key escrow.

Ten‑minute hands‑on device audit

Do a short hands‑on check on a sample device to verify permission prompts, camera/mic indicators, app provenance and network egress. Run this with IT present; it takes about ten minutes per device and reveals when a vendor relies on platform defaults rather than securing their stack.

• Permission prompts: factory‑reset or create a new profile and confirm the device requests camera and microphone access at runtime and allows denial.
• Camera/mic indicators: confirm a visible LED or on‑screen indicator when camera or microphone are active; check the device manual for Ray‑Ban Meta, Vuzix and XREAL models if unsure.
• App provenance: confirm apps come from the device's official store or inspect APK signatures for sideloaded Android XR or XREAL apps.
• Network egress: monitor outbound connections from the companion phone or device while idle and while the camera/mic are active to see destination hosts.

Validate the app ecosystem and third‑party apps

Request a current roster of supported apps and the vendor's app review process. You must be able to control which apps run on business devices and to push or block updates centrally; require package names and publisher IDs so installed software can be matched to the approved list.

• Approved apps roster: signed list with package names and publisher IDs to match installed packages.
• App review: description of the vetting process, including checks for data exfiltration and excessive permissions.
• Update controls: whether vendor or IT can block installations and require apps to use an enterprise update channel.
• Use our directory to check known apps: search supported apps in the /apps index and device pages such as /devices/ray-ban-meta, /devices/xreal-air-2-ultra and /devices/vuzix-shield.

Contract levers procurement must use

Include audit rights, a data processing addendum (DPA), security SLAs for patching, breach notification timelines, and indemnities tied to vendor negligence in your RFP and contract. These clauses give procurement enforceable remedies and the right to verify remediation evidence during pilots or audits.

• Audit rights: ability to run or commission security assessments and receive remediation evidence.
• DPA: maps responsibilities for personal data, retention, subprocessors and deletion on termination.
• Security SLAs: deadlines for patches and a forced update requirement for critical vulnerabilities.
• Indemnity and liability: vendor responsibility for breaches caused by their negligence with measurable remediation timelines.

How this fails in practice

Procurements fail when buyers accept badges and high‑level assurances without verification. Typical pattern: procurement accepts a compliance badge, a pilot starts, then users notice unexpected uploads or battery drain and patching or forced updates are absent or slow.

• Pilot symptoms: users report unexpected uploads or battery drain; IT finds unlogged outbound connections.
• Root causes: compliance badges can hide scope limits; vendors may patch but not force updates; companion apps create unmonitored network paths.
• Mitigation: require evidence up front and exercise audit rights during pilots; if a vendor resists live access, score them lower.

What to do next

Run the checklist against each shortlisted vendor, request the listed documents, and perform the ten‑minute hands‑on test on a sample device. Score vendors on verifiable evidence and treat missing audit/pentest reports, no signed update policy, lack of raw stream disclosure, or no contract audit rights as disqualifiers.

Where this usually goes wrong

• Vendor supplies only redacted or summary audit reportsThe audit scope excluded device backends and apps or the vendor is protecting commercial details.Insist on an auditor letter stating scope and dates, or commission a joint third‑party assessment during the pilot; treat redacted reports as insufficient.
• Device streams video without a visible indicator or permission promptApp or firmware uses platform APIs without exposing runtime consent or the vendor disables indicators.Fail the device during the pilot and require a firmware update that enforces runtime consent and shows a hardware or on‑screen indicator before proceeding.
• Vendor agrees to patch timelines verbally but cannot force updatesArchitecture relies on voluntary user updates rather than a centrally enforced update channel.Require a signed update policy with forced‑update capability or an enterprise management channel as a contract condition before purchase.
• Third‑party apps request excessive permissions and cannot be blockedVendor provides an open app ecosystem without enterprise app controls.Require a roster of approved apps and central app blocking/whitelisting controls in the contract, or disqualify the vendor if they cannot provide this.

The checklist

• Request audit and pentest reports
• Get the signed update and patch policy
• Obtain data‑flow diagrams and retention rules
• Perform the ten‑minute hands‑on test
• Validate app provenance and controls
• Check incident response and VDP
• Negotiate contract security clauses
• Score vendors and decide

Frequently asked questions