Firmware Download URLs That Expire Mid-Campaign: Preserve Artifact Identity When Renewing Access

Renew permission to fetch the same approved artifact, not permission to accept whatever bytes a new URL returns. Keep artifact identity and applicability separate from the short-lived transport locator. A renewed link can restore access while the expected payload digest, size and authorization remain unchanged.

This guide uses Amazon S3 presigned-URL behavior documented on 14 October 2026 as a concrete service example, plus RFC 9124’s payload-location model. Other services can have different expiry and redirect rules. No credentials, URLs or cloud resources were created, and no download was performed.

1. Separate four lifetimes

Lifetime	What it controls	What renewal does not prove
Transport URL validity.	Whether a particular fetch request is authorized.	That its bytes match the approved release.
Underlying credential/session validity.	Whether the service still accepts the URL’s authorization basis.	That the configured URL expiry is the effective expiry.
Artifact or manifest acceptance.	Which payload and metadata the device may trust.	That installation is currently scheduled or compatible.
Campaign execution permission.	Whether this device may proceed now.	That renewing network access extends the campaign.

RFC 9124 section 3.12 describes payload acquisition information, including one or more URIs. Treat that location as part of the acquisition contract while retaining the product’s authenticated payload identity and acceptance policy.

The client record should include an opaque artifact identifier, expected length and digest, approved metadata identity, campaign revision and locator generation. Store the actual access token only in the protected channel or memory required by the implementation; routine support logs should use a redacted reference.

2. Use the service’s real expiration semantics

The S3 presigned-URL guide states that expiration is checked when the HTTP request begins. A download started before expiry can continue afterward, but a new request after a dropped connection can fail once the URL has expired.

The same guide explains that temporary credentials can expire before the requested URL lifetime. Revoked or deactivated credentials can also invalidate access, and service policy can impose additional restrictions. Do not diagnose every early denial as a client timer bug.

This matters for range-based or reconnecting downloaders: one long response and a sequence of new requests can encounter different expiry boundaries. A successful initial request does not reserve access for every later range or retry.

Use a documented request budget and renewal margin appropriate to the service. Do not turn that margin into an unlimited promise that a large download will finish before access changes. Preserve the overall campaign deadline while evaluating renewed access.

3. Classify failure before requesting another URL

Retain the bounded service error class, request generation and stage without copying the URL query into logs. A generic forbidden response can reflect expiry, permissions, network restrictions or request-signature mismatch. Use the service’s documented details and the issuing authority’s view rather than assuming every denial can be repaired by renewal.

Observation	Next decision
Confirmed transport credential expiry.	Request renewed access for the same approved artifact.
Campaign was withdrawn or superseded.	Stop that operation and reconcile the campaign decision.
New locator resolves to different payload identity.	Reject substitution; require a separate artifact approval.
Access denied for an unresolved reason.	Bound retries and report the specific uncertainty.
Service cannot renew access within budget.	Defer or fail acquisition without reporting installation success.

Do not disable TLS verification, broaden access permissions or switch to an unauthenticated mirror to hide a renewal failure. Those actions change the security contract rather than restoring the original fetch permission.

4. Bind renewal to the original artifact

1. Send the approved artifact reference and current campaign/request generation to the established renewal authority.
2. Validate the response through the existing authenticated service channel.
3. Require the artifact reference, expected digest, length and applicability to remain consistent with the approved record.
4. Accept only the locator and access-lifetime changes that the renewal contract permits.
5. Invalidate stale locator callbacks so they cannot overwrite a newer decision.
6. Recheck campaign eligibility before resuming acquisition or advancing installation.

A visible filename or object key alone is insufficient if the service can replace the object under that name. Prefer the service’s supported immutable version binding where applicable, and still verify the payload identity required by the update contract.

If renewal intentionally selects a different release, treat that as a new update decision. Do not amend the expected digest silently merely because the refreshed response contains a different value.

5. Revalidate partial-download state

Keep accepted partial data tied to the original artifact identity and the downloader’s verified checkpoint contract. A new URL does not automatically invalidate good partial data, but it also does not prove that resuming at the old offset is safe.

Use the downloader’s qualified representation-consistency checks and verify the completed artifact. If identity or checkpoint provenance cannot be established, restart acquisition into a controlled staging area according to policy. Never concatenate bytes from unrelated object versions and rely on a plausible file header.

Qualification must use the actual HTTP method and signed request requirements. For S3, the guide notes that request parameters, headers and query content must match the signed request. A renewal service must support the downloader’s required access pattern rather than issuing a superficially valid link for a different request.

Streaming installation requires additional care because some target work may already have occurred. Replacing a locator cannot rewind those writes. Use the updater’s documented failure and retry behavior, preserving the original artifact and destination state.

6. Test renewal without exposing bearer access

S3 describes presigned URLs as bearer access: possession can grant the permitted operation. Keep test locators out of screenshots, shell history, exception messages and public fixtures. Use an authorized disposable service fixture and non-sensitive objects for any real qualification.

• Start a request before expiry and keep it open across the boundary.
• Drop the connection and attempt a new request after expiry.
• Exercise an earlier underlying-session expiry.
• Renew to the same artifact, then deliberately offer a different artifact.
• Deliver an old renewal response after a newer campaign revision.
• Test the supported redirect path without forwarding access material to an unapproved destination.

These tests were not executed. Preserve redacted outcomes and artifact identities, not live access strings.

Hypothetical interrupted range download

A gateway begins fetching an approved image before its S3 URL expires. After a network interruption, the next request fails. The client obtains a new locator for the same immutable artifact, verifies the renewal record and resumes only through its qualified checkpoint path.

If the renewed locator points to a different release, acquisition is held for a new approval. The distinction keeps transport recovery from silently becoming an artifact-selection change.