The Update-Runway Test: How Many Secure Years Are Left Before You Buy a Phone?

A phone can be supported today and still be a poor long-term purchase. “Supported” is a present-tense answer; a buyer needs a future-tense one. The update-runway test asks whether enough secure time remains after the purchase date to cover the intended ownership period, repairs, and a margin for delays.

The test takes fifteen minutes when a manufacturer publishes clear dates. It takes longer when commitments are written as operating-system generations, vary by region, or are buried in launch announcements. That difficulty is itself information: uncertainty should lower the value assigned to the promise.

The pass-or-fail question

Define the intended ownership end before researching the phone. If buying in September 2026 for four years, the target is September 2030. Add a margin—six or twelve months is practical—so replacement is planned rather than forced by a final patch.

The phone passes the basic test only if primary-source evidence supports security maintenance beyond the target plus margin. A phone with support expected to end in October 2030 barely covers the four-year plan and fails a twelve-month-margin test. A device supported into 2032 passes more comfortably.

This is a purchasing filter, not a prediction of hardware survival. A passing phone still needs adequate battery service, storage, performance, and repair options.

Write the ownership target first

Without a target, every long promise sounds good. Choose a period that matches how the phone will be used:

• A budget primary phone may be planned for three or four years.
• A premium phone may need five or six years to justify its price.
• A company fleet may follow a fixed replacement and compliance cycle.
• A secondary offline device may not use the security endpoint as its main limit.

Do not stretch the target merely to make an expensive option look economical. Use past behavior, budget, app needs, and willingness to replace a battery.

Identify the model beyond its marketing name

Record the exact model number, storage, region, carrier version, and release generation. Similar names can cover multiple years. A marketplace listing may default to a newer version while the selected color or capacity belongs to an older device.

Ask a used or refurbished seller for a photograph of the About screen with personal identifiers obscured. Compare it with the box and listing. An imported model can have different network behavior and service access even when its update policy appears similar.

If the seller will not identify the device, the test stops. Unknown model means unknown runway.

Collect two independent primary records

First, find the manufacturer’s policy page, supported-device list, or launch commitment that names the model. Second, find the current update or security-release record showing that eligible devices are actually receiving maintenance.

The policy establishes the promised horizon. The release record establishes present delivery. One without the other is incomplete. A phone may have a generous published policy but be months behind because of a carrier or rollout problem. A phone may receive an exceptional patch after support without gaining a new continuing promise.

Save the links and the date checked. Support pages can be updated, renamed, or reorganized.

Separate three endpoints

Create three rows: major operating-system upgrades, security updates, and essential app compatibility. Do not put one date beside the word “updates.”

For primary-phone security, the security-maintenance endpoint is the basic runway boundary. Major upgrades can end earlier without immediately making the phone unmaintained. App support may end earlier or later depending on the developer.

A buyer who needs an employer’s management app should ask the employer for its minimum version and patch rules. A phone can pass the manufacturer test and fail the work test.

Find when the clock started

Read the exact wording: from launch, first availability, a named month, or a number of version upgrades. Do not start the clock when the current owner buys or activates the phone unless the maker explicitly says so.

For fixed calendar terms, calculate the endpoint using the stated start. For a device-generation promise, identify which upgrades have already been delivered and avoid inventing a precise month for releases that do not exist yet.

A sealed phone does not preserve software time. Inventory age is one reason an older new phone needs the same runway test as a used one.

Calculate raw runway

Use months:

Raw runway = documented security endpoint − intended purchase date.

If an exact endpoint is unavailable, produce a low and high estimate. The low estimate should use the cautious interpretation of the policy. Label both as estimates, not official dates.

Then compare raw runway with planned ownership plus margin. The arithmetic is simple; the evidence behind the dates is the real work.

Apply an uncertainty deduction

Not every promise deserves equal confidence. Use a small deduction when the evidence is ambiguous:

• No deduction: official page names the exact model and endpoint.
• Three to six months: clear duration and start, but no exact end date.
• Six to twelve months: commitment depends on version cadence or regional interpretation.
• Fail: only retailer copy, forum posts, or historical pattern supports the claim.

This is a buyer’s safety margin, not a statement that the maker will break its promise. It prevents uncertain time from being valued like documented time.

Apply a delivery check

Inspect the actual phone’s security patch level or iOS version. Use the official update process while connected to reliable power and network service. Allow for staged rollout, but ask why a device is far behind.

Storage shortage, carrier approval, an imported variant, enterprise management, or failed installation can explain a lag. The seller should resolve it before the return window closes. Do not accept “it updates eventually” when current eligibility can be tested.

A pass requires both future runway and credible present delivery.

Apply a repairability check

A six-year update promise has little ownership value if a worn battery cannot be replaced where the phone will be used. Find the manufacturer or qualified local battery price, part availability, turnaround, and warranty.

Check display repair too. Accidental damage is not guaranteed, but a screen price near the cost of another phone can end the plan. Add the likely battery service to total ownership cost.

The update-runway test should not certify software time the hardware has no reasonable path to reach.

Apply a storage check

Estimate local storage at the planned end date. Include the operating system, app growth, photos, messages, downloads, offline maps, and working room. Cloud storage moves some data but adds a subscription and does not replace all local capacity.

If the phone begins nearly full after migration, it fails a long-term runway test even with years of patches. Storage is usually fixed. Buy capacity for the planned period or shorten the plan.

Apply an app and accessory check

List the applications and connected products that define the role. Review current minimum operating-system requirements. Check watches, vehicles, hearing devices, drones, payment systems, security keys, and employer tools.

The goal is not to predict every developer’s policy. It is to catch an incompatibility that already exists or a requirement close to the phone’s limit. Mark uncertainty where an essential vendor provides no support information.

A strong firmware runway cannot repair an absent required feature or radio.

Score the result

Use four outcomes:

• Pass: documented runway exceeds the plan plus margin, current delivery is verified, and hardware can plausibly last.
• Conditional pass: adequate runway, but a battery, storage choice, or seller action must be included.
• Short-term only: supported now, but not long enough for the planned period.
• Fail: unsupported, model unknown, evidence weak, or a critical app and repair requirement cannot be met.

This language is more useful than assigning a mysterious score out of ten. It also states what would change the answer.

Example: an older flagship

A refurbished flagship costs $380 in September 2026. The buyer wants four years. Official evidence supports security maintenance only through late 2028. Battery health is guaranteed above 80 percent, and replacement costs $110.

The phone is supported today but offers roughly two raw years, far short of the four-year target plus margin. It receives “short-term only.” A beautiful display and strong processor do not add software runway.

It might still suit a buyer explicitly planning two years, if price, battery, and warranty compare well. The test changes with the plan, not with nostalgia for the model.

Example: a current midrange phone

A current midrange device costs $460 and has documented support beyond 2032. The buyer plans four years. Current updates install normally, local battery service is available, and 256 GB capacity fits projected use.

It passes with margin. Its camera may be less capable than the old flagship, so the final decision still involves features. The test says the support promise is credible for the plan; it does not say the phone wins every category.

Example: an uncertain marketplace import

A seller lists a model as “five years updates,” but the page combines regional variants and provides no model number. The manufacturer policy names only certain versions. Local warranty and eSIM support are unclear.

The phone fails until the seller supplies an exact model and primary evidence. A low price cannot be divided by supported years that have not been established.

Use the result in price negotiations

A short runway should reduce the price because the buyer receives fewer secure primary-use years. Calculate cost per supported year and compare it with a current alternative. Include battery and charger needs.

Show the seller the official endpoint politely. A seller is not required to accept your valuation, and you are not required to buy. Do not let a general claim such as “still gets apps” replace security evidence.

Keep the evidence after purchase

Save the policy link, screenshots, receipt, exact model, and calculation. Check the patch level after setup and every few months. If delivery stops while the policy still includes the model, contact the manufacturer or carrier promptly.

Set a review date six to twelve months before the support endpoint. Prepare backups, authenticator transfers, and a replacement budget before the final month.

For the underlying date calculation, use our step-by-step guide to remaining phone updates.

The practical answer

The update-runway test asks one disciplined question: does primary evidence provide enough secure time from the purchase date to the planned replacement date, with a margin? A phone passes only after the exact model, policy, current delivery, battery path, storage, and essential apps agree.

Runway is consumed time. Do not buy an old promise at a new-phone price. Buy the supported months that remain and a device with a credible physical chance of reaching them.

Sources

• Google: Pixel software update policy
• Samsung Mobile Security: Scope of security update support
• Apple Support: Apple security releases
• Android Open Source Project: Android Security Bulletins

Last reviewed: September 6, 2026. Policies, supported models, release schedules, and regional availability can change; repeat the test before purchase.