Do not retire an old proxy credential just because one request works with its replacement. First identify every consumer, prove each has loaded the intended version on a fresh connection, and account for work still using the old version. Then perform the authorized revocation and verify it separately. A configuration edit, a successful request and a completed revocation are different evidence.
This checklist is for operators of authorized collection or regional QA workloads planning a routine service-credential change. It helps decide when to hold, proceed or close the change window. Suspected exposure is an incident: follow the owner's containment procedure and the production incident runbook. Do not delay urgent revocation to finish a batch, or restore a potentially compromised credential to preserve availability.
Choose a procedure your provider actually supports
Before scheduling the change, get current documentation or an accountable support answer for your credential type and account: can old and new credentials coexist, can either be revoked independently, what scope does revocation cover, and what happens to existing connections? Record any documented propagation interval and the authoritative status or audit event used to verify the action. Unknown answers are planning gaps, not implied capabilities.
| Confirmed condition | Procedure | Hold condition |
|---|---|---|
| Scoped overlap and independent revocation are supported | Provision through the approved channel; test the new version, migrate consumers, drain old work, then revoke the old version. | A consumer is unverified, old work remains, or the revocation scope is unclear. |
| Only one credential can be active, or overlap is unknown | Arrange an approved pause or maintenance window. Stop new work, drain or safely checkpoint jobs, prepare the reload path, change the credential, validate fresh connections, then resume gradually. | There is no approved interruption or safe stop/recovery procedure. Resolve that before changing the credential. |
The second procedure has an interruption between invalidating the previous credential and making consumers usable with the replacement. Do not describe it as zero downtime or assume the provider and your secret store update atomically. Before revocation, rollback to the previous version is an option only if it remains valid, uncompromised and explicitly approved. After revocation, hold affected work and repair the new path or use an approved replacement; do not silently reactivate the old secret.
Inventory consumers, including the ones that are asleep
Assign an owner and a change-window identifier. List deployed instances, batch runners, retry queues, scheduled jobs, manual tooling and recovery deployments. Expand a fleet into individually evidenced instances or justify how a deployment-level record covers them all. The four consumers below are four fictional instances, not four categories representing an unknown fleet.
For each, record a harmless credential-version alias, the reference configured for the next start, the version actually loaded, a fresh authentication check, old-version jobs and connections, and a private evidence reference with time and owner. Do not export secret values, secret hashes, credential-bearing URLs, environment dumps or raw authorization headers into the worksheet. Use the redacted evidence handoff when requesting help.
Changing a stored value does not prove an application adopted it. For example, Kubernetes documents that a running container does not see a changed Secret through an already injected environment variable without restarting it. Secret-backed volume updates are eventually consistent, and subPath mounts do not receive automatic updates. Even after a file changes, verify that your application rereads it. These are Kubernetes behaviors, not a claim about IPHTML or every runtime.
A readiness probe must use the intended version and expected proxy path on a new connection to an authorized harmless target. Keep the same protocol, account scope and relevant gateway or region when comparing versions. Verify the responder and authentication result; a target page returning HTTP 200 alone does not prove which credential was used. The actual-route checks explain why a terminal success can differ from a worker's result.
Replay a change window before trusting the checklist
Download the 12-row credential retirement worksheet. It contains synthetic observations for four named consumers at three snapshots. It is an editable decision example, not an executable rotator, real customer log or IPHTML test. v1 and v2 are labels, never passwords. Times are fictional, within one window and time zone; they prescribe no waiting interval.
At each snapshot, a consumer is ready only if configured_alias = loaded_alias = v2, fresh_auth = pass, old_jobs = 0 and old_connections = 0. An unknown value fails this gate. “Loaded” must come from the consumer's version-aware configuration record, without logging the secret; if the runtime cannot expose trustworthy evidence, keep that field unknown. Do not sum snapshots or substitute a target response for authentication evidence.
| Snapshot | What changed | Ready consumers | Decision |
|---|---|---|---|
| 09:12 | API worker is ready. Batch runner still uses v1 with two jobs and one connection. Retry worker has v2 configured but v1 loaded. Nightly job has not been exercised. | 1 of 4 | Hold. Zero active jobs on the retry worker would not prove it loaded v2. |
| 09:25 | Batch jobs drained; old pool closed; batch and retry workers loaded v2 and passed fresh checks. Nightly job remains unverified. | 3 of 4 | Hold. A dormant consumer cannot be counted as migrated. |
| 09:32 | An authorized controlled activation verifies the nightly job with v2; all four have zero old jobs and connections. | 4 of 4 | Pre-revocation ready, provided the owner confirms the inventory is complete. Old credential retirement is not yet verified. |
To reproduce the counts, open the CSV in a spreadsheet, group by snapshot, and count rows satisfying all five conditions above. Expect 1, 3 and 4. Then change the final nightly row's fresh_auth to unknown: the last count falls to 3 and the decision returns to hold. Add a fifth unverified consumer and the final state is 4 of 5, also hold. Keep the original file for comparison and use a separate copy for a real change.
These counts are arithmetic about a declared inventory. They do not discover missing consumers, revoke anything, or prove provider availability. The owner must separately reconcile deployment inventory, schedules and credential references. If a scheduled job cannot run safely now, explicitly prevent it from starting with the old reference and verify its replacement path before enabling it; an undocumented assumption that it will reload later is insufficient.
Verify revocation after the authorized action
OWASP treats rotation and revocation as separate secret-lifecycle steps. For this checklist, closure needs the following evidence in addition to the consumer worksheet:
- Action and scope. Record the authorized operator, time, harmless old-version alias and provider status or audit confirmation. Account for the provider's documented propagation behavior; if no bound or reliable status is available, keep the result unresolved and consult the owner.
- Controlled fresh checks. Where authorized, verify that a new connection using the old version is rejected specifically by the intended authentication layer, while a matched fresh check using the new version succeeds. Limit probes to the approved scope. A timeout, DNS failure, 403 or 407 by itself is inconclusive. Use the 407 diagnostic guide to establish which layer responded.
- Existing connection state. Confirm old pools and jobs are drained or terminated under the approved procedure. A fresh old-version rejection says nothing by itself about an already authenticated connection. Follow the provider's documented session behavior; do not assume password changes disconnect sessions.
- Recovery path. Check references in rollback revisions, job templates and approved recovery artifacts. A controlled restart or restore must resolve the current external secret reference and pass a fresh check. Remove obsolete usable references through the approved process; one tested revision does not validate every historical image.
In an extended fictional window, the owner could record scoped revocation and matched checks at 09:35, followed by a tested recovery revision at 09:40. These are example evidence slots, not results from a provider. Set the real observation period to cover the affected workload's restart, retry and scheduling behavior; record unresolved consumers and the next check instead of declaring completion after a fixed five minutes.
Use the result to assess a long-term provider fit
A useful acceptance requirement is operational: can your team change credentials within its interruption allowance, identify all affected consumers, and obtain reliable revocation evidence? A larger advertised IP pool does not answer that question. If a direct approved route meets the workload's needs, additional proxy infrastructure may add unnecessary operational work.
If you are evaluating residential proxies or rotating proxies, compare their suitability for your authorized workload, then ask IPHTML about the credential lifecycle required by your integration. Share a redacted consumer list, protocol, region and acceptable maintenance window. Confirm overlap, revocation scope and support procedures for the actual account before committing to a rollout. This article establishes none of those IPHTML capabilities or a performance guarantee.
Sources and scope
Checked November 5, 2026: OWASP secret lifecycle; Kubernetes Secret injection; Kubernetes Secret volume updates. The readiness rule and worksheet are original operational analysis. Only their synthetic logic was replayed; no live credential was changed, tested or revoked for this article.