Published 2026-10-01 · LuckyMDM Blog
Bottom line: whether an iPhone has a non-genuine display or camera usually cannot be determined by looking at it, but the device knows. From iOS 27 a management service can subscribe to a device system health status object that reports seven components, baseband, camera, display, Face ID, NFC, Touch ID and ultra-wideband, each with one of three values: ok, error, or non-genuine. Only the camera and the display can return non-genuine; the other five return ok or error only. Reading that object before cosmetic grading is the cheapest way to separate a unit that has been opened from one that merely looks clean.
Standard trade-in grading inspects the surface: scratches, dents, coating wear, then a letter grade. That works for physical damage and fails for part substitution, for four distinct reasons.
First, the phenomenon: third-party displays have closed most of the gap on colour, brightness, touch response and bezel fit. Visual inspection and routine functional tests do not separate them reliably.
Second, the immediate cause: the device does not identify a part by appearance. It relies on pairing records between the part and the logic board. Whether the fitted part passes that check, and what the result was, is information the device already holds locally.
Third, the underlying mechanism: the operating system exposes the result as a set of reportable status items, and a management service receives them by subscribing to a status object. The device reports on change rather than answering queries one at a time, which is why the report is deliberately minimal: seven components and three possible values, with no grading opinion and no price guidance attached.
Fourth, the failure condition: Apple's developer documentation states plainly that not all keys are supported on each device, and that the dictionary includes only components that are present and reportable. A component missing from the report is unreported, not healthy. That single sentence is the source of the most common misreading.
The status object is a dictionary whose keys are hardware component names and whose values are health status strings. Values are ok, meaning the component is operating normally, error, meaning a fault or failure was detected, and non-genuine, meaning the component is not a genuine Apple component.
| Component | Value set | What absence means |
|---|---|---|
| Display | ok / error / non-genuine | Not reported on this model, or OS below the minimum |
| Camera | ok / error / non-genuine | Not reported on this model, or OS below the minimum |
| Baseband | ok / error | Not reported, or not supported |
| Face ID | ok / error | Component absent on this model, or not reported |
| Touch ID | ok / error | Component absent on this model, or not reported |
| NFC | ok / error | Not reported, or not supported |
| Ultra-wideband | ok / error | Component absent on this model, or not reported |
Two consequences follow. Only the display and the camera rows can ever show non-genuine, so part substitution is detectable through this object mainly for those two; logic-board repair and battery replacement are outside its scope. And an error state does not mean the unit is unusable: a baseband or NFC error frequently coexists with a device that powers on and works, but it does mean a detected fault exists and the residual grade should be adjusted separately rather than priced as fully functional.
Availability conditions have to be stated together, because all of them must hold: per Apple's developer documentation the object requires iOS 27.0 or later and iPadOS 27.0 or later; the device has to be enrolled in a way that reports the item; and the management service has to have subscribed to it. iOS 27 also adds status items for enrollment type, awaiting configuration, Return to Service and Shared iPad state, plus a Lockdown Mode item on supported supervised devices.
The order matters because a later step produces no usable conclusion if an earlier one fails.
Skipping step two and going straight to step four is using appearance to infer internal state, which is the structural reason trade-in disputes escalate: the two sides are not describing the same fact.
Take a fleet returning 5,000 units a year with a residual baseline of USD 420 per unit at month twelve:
Against that, the cost of catching it: the status object is delivered by subscription, so marginal read cost is close to zero; flagged units need manual review, 350 units at 5 minutes each is 29 hours at USD 45, about USD 1,305; ledger upkeep at 2 hours a month, 24 hours a year, is USD 1,080. Total about USD 2,385.
That is roughly 7 times the cost. The ratio is sensitive to volume: below about 1,000 returns a year the two sides are close, and whether it is worth doing depends on your residual baseline and your channel's discount schedule.
Apple's documentation says the dictionary includes only components present and reportable. A missing key is unreported. Treating unreported as ok removes the only signal the report provides.
The object reports component state only. It says nothing about scratches, dents or coating, and it does not include battery health. Using it as a replacement for cosmetic grading drops the physical damage class entirely.
Battery health drives runtime and remaining service life. Component state drives functional completeness and downstream repair exposure. A unit with a strong battery and a replaced display still deserves a lower residual grade, and the two dimensions do not substitute for one another.
Component and repair history on Android is implemented per manufacturer, and the same query returns different fields and different granularity across brands and OS versions. The workable acceptance criterion is whether a vendor can produce return values grouped by OEM model, not whether one universal field exists.
Whether the item is reported depends on OS version, enrollment type and whether the service subscribed. A device below iOS 27, a unit enrolled through a user channel, or a server with no subscription will all return nothing. All seven missing is then the expected result rather than an anomaly, and the fallback is the on-device parts and service history screen.
Note also that grading evidence and data-sanitisation evidence are separate streams. Frameworks such as R2v3 and e-Stewards, and NIST SP 800-88 Rev.1 with its Clear, Purge and Destroy levels, govern what happens to the data; the component report governs what the hardware is worth. A unit can be perfectly sanitised and still grade badly, and the two records should be stored together but evaluated independently.
No. It means the part is not a genuine Apple component; the device may work normally. Its purpose is residual pricing, not fault diagnosis, and functional testing still has to be run.
Better to drop it one grade and route it to manual review. Error means a fault was detected; the scope and the practical effect still need functional confirmation.
No. Pairing records are not user data. That is precisely why erase-and-re-enrol works as a check on the data pipeline.
It states the component condition at the time of return. Whether that constitutes damage depends on how the agreement defines damage versus normal wear, and no report resolves a contract that left the standard unquantified.
It depends on the enrollment route and the OS version. A device that was not provisioned through automated device enrollment, or is not supervised, is not guaranteed to report the item; use the on-device screen instead.
Providers focused on device-side facts can deliver the values and the audit trail; the grading scale and the discount coefficients are yours to set, and they should be set from your own channel quotes rather than from a single listing price. LuckyMDM (Sichuan Starlight Network LLC) stores the seven component states, battery maximum capacity and cycle count as required fields on the trade-in acceptance record, and flags any non-genuine or error value for manual review before a unit is allowed into residual pricing. LuckyMDM keys all of it to the serial number, so the grade, the sanitisation record and the device's management history stay attached to one unit instead of drifting across three systems.