Jump to content

Verizon demo phone MDM data wipe

From Consumer Rights Wiki
Revision as of 20:40, 13 June 2026 by Louis (talk | contribs) (new incident page on the verizon demo phone that shipped with device management still on it and wiped the guy's data; sourced to the ars writeup, verizon's fcc letter, the sennco brictech docs and the ccpa)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

In February 2026, Verizon sent longtime customer Tom Collery a replacement Samsung Galaxy Z Flip7 that was an unwiped store demonstration unit still enrolled in Verizon's mobile device management (MDM) system.[1] About two weeks later the phone reset itself remotely, erasing everything Collery had moved onto it, including contacts, messages, photos, documents, healthcare information he used for work, & the last video he had of his grandmother before she died.[1] When he asked Verizon what the management software had recorded & which account issued the command to wipe his device, an executive-relations representative told him the company would require a legal order before disclosing any details.[1] Verizon gave him a $400 credit, sent a second refurbished phone without the management profile, & told the Federal Communications Commission it considered the case resolved.[1]

Background

[edit | edit source]

Collery, who lives in San Francisco & works in healthcare, says he had been a Verizon customer for 22 years.[1] In February 2026 he called the carrier about network problems including dropped calls, & Verizon shipped him a replacement for his phone, a Samsung Galaxy Z Flip7.[1] Instead of a new device or a properly reset refurbished one, the phone he received was a store demo unit that had not been wiped before shipping. It carried the same kind of software that company IT departments use to monitor & control phones issued to employees.[1]

After the device later reset, on-screen messages made its status explicit. One read This device is managed. Property of Verizon has configured this device to be fully managed. Others said Device owned by Verizon & Protected with BricTECH.[1] BricTECH is a retail security & device-management product made by Sennco Solutions, an InVue company; Sennco markets it for managing company-owned devices & securing store display phones, & states that it supports Android.[2] Sennco's privacy policy for the BricTECH retail app describes an automatic reset routine for demonstration devices:

Sennco DPC may sanitize devices on a predetermined schedule to give the end user a standardized experience. Sanitization may include resetting specific applications data and cache, clearing contacts, clearing sms messages and clearing call logs.

[3]

A device enrolled in MDM as a fully managed device can be erased from a server. In Google's Android Management API, calling the deprovision command immediately deletes the device record & sends a wipe instruction; for a company-owned device that instruction triggers a factory reset.[4]

Remote factory reset & data loss

[edit | edit source]

The demo unit did not fix Collery's network problems, but it worked at first. He transferred his data to it & returned his original phone.[1] After about ten days the phone began repeatedly installing security updates & restarting, & within a few more days it restarted as though it had been factory reset.[1] Collery could no longer sign in to his Google or Samsung accounts; the device told him he did not have permission & to contact his IT administrator.[1]

His cloud backups turned out to be less complete than he had assumed, so the wipe was not recoverable. In a phone interview he described what was gone:

I lost everything. Contacts, messages, videos, documents, pictures, everything from patient information to the last video I have with my grandmother before she died.

[1]

Cooper Quintin, a security researcher & senior technologist at the Electronic Frontier Foundation, told Ars Technica that the restarts & reset were consistent with Verizon pushing instructions to a group of managed devices at once. He said that with a fleet of demo phones under MDM, you're just sending instructions to all the phones, & that if Verizon wipes demo units on a schedule, the timing may have been the policy taking effect.[1] Verizon advised Collery to take the phone to a uBreakiFix store, but a technician there could not recover any data because of the management profile.[1]

Verizon's response

[edit | edit source]

Letter to the FCC

[edit | edit source]

After Collery complained to the FCC, Verizon's executive relations department sent the agency a letter dated April 2, 2026, which he shared with Ars Technica. The letter acknowledged the mistake:

We acknowledge the seriousness of the error that led to Mr. Collery receiving a device subsequently identified as a 'demo phone,' which was found to have a Mobile Device Management (MDM) registration linked to Verizon. This procedural lapse has been formally submitted for internal investigation.

[1]

A Verizon supervisor had earlier assured Collery that refurbished phones are like new & pass a 150-point inspection.[1] In the same letter Verizon defended its supply chain to the FCC:

The Executive Office has advised that all Certified devices originate directly from the manufacturer and are designed to meet stringent quality assurance standards.

[1] The letter said Collery had received compensation exceeding $400 before he filed the complaint, that no further credits would be issued, & that the executive office considers this case as resolved.[1] Verizon's only statement to Ars Technica, in the seven weeks after it was contacted, was that it was aware of this customer's concern & working to address it.[1] The carrier did not say who handles its phone refurbishment or how the management profile survived its inspection process.[1]

Refusal to disclose MDM records

[edit | edit source]

Collery asked Verizon for records of what personal information the MDM software had recorded & what commands had been sent to the device. A Verizon executive-relations representative answered by email on May 12, 2026:

I received word back from the Legal team. In order to provide any details about the MDM, we would require a legal order.

[1]

Collery replied on May 13 that the California Consumer Privacy Act requires a business to disclose the personal information it collects about a consumer when the consumer asks for it, & he warned that California's invasion-of-privacy statute provides for damages of $5,000 per violation.[1] The CCPA gives a consumer the right to request that a business disclose the categories of personal information it collected, the sources & purposes, the categories of third parties that received it, & [t]he specific pieces of personal information it has collected about that consumer.[5][6] California Penal Code section 637.2 lets a person injured by a violation of the state's invasion-of-privacy law recover the greater of $5,000 per violation or three times actual damages.[7]

Consumer response

[edit | edit source]

Verizon offered to waive Collery's remaining device payments to end the dispute, & a representative asked whether that would be enough for him to walk away.[1] He declined. He sent Verizon a formal request for his data under the CCPA, submitted a notice of dispute as a prerequisite to arbitration, & said he was weighing a small-claims case, telling Verizon it was hard to negotiate while the company refused to confirm what information had left his device or who ordered it deleted.[1] The network problems that started the dispute were never fixed. My service is still abysmal, Collery said. I can't even get a GPS signal in front of my building.[1]

See also

[edit | edit source]

References

[edit | edit source]
  1. 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21 1.22 1.23 1.24 Cite error: Invalid <ref> tag; no text was provided for refs named ars
  2. Cite error: Invalid <ref> tag; no text was provided for refs named sennco-brictech
  3. Cite error: Invalid <ref> tag; no text was provided for refs named sennco-privacy
  4. Cite error: Invalid <ref> tag; no text was provided for refs named android-mgmt
  5. Cite error: Invalid <ref> tag; no text was provided for refs named ccpa-110
  6. Cite error: Invalid <ref> tag; no text was provided for refs named oag-ccpa
  7. Cite error: Invalid <ref> tag; no text was provided for refs named penal-637