A sixth escalation begins when post-fifth-re-release surveillance proves that a prohibited authority can bypass the repaired broker through a local archive group and shared service identity. Recovery must stop that path without confusing access exposure with a change to polymer results.
This guide shows how to freeze delegation evidence, revoke and rotate a service identity, repair the earliest synchronisation rule, reconstruct package actions, redesign ownership and re-release only after renewal, synchronisation and token-refresh tests all deny the retired authority.
The Gold Standard is revocation with continuity. Remove effective authority quickly, but preserve enough logs, package versions and workflow traces to say what happened, what did not happen, and why the repaired system is safe to release.
A practical orientation
Treat a service identity as an actor with callers, credentials, permissions, owners and package consequences. Revoking the credential without repairing its delegation graph allows another credential to recreate the same authority.
The worked example contains a synthetic export and no production export. Recovery therefore addresses a real control failure while keeping the scientific conclusion precise: package confidentiality was exposed in capability, but production use and integrity require separate evidence.
- Stabilise the escalation — for identity and quality owners.
- Revoke the service path — for archive and security teams.
- Follow the archive recovery — for a complete evidence example.
- Apply sixth re-release gates — for controlled restoration.
- Transfer the method — for another vendor or automation account.
Chapter contents
Open a route that matches the decision in front of you, or read straight through. Each route returns to the same evidence chain.
Start with the operating question
Build the evidence chain
Map the service-identity delegation graph
Work the example
Stress-test the decision
1. Stabilise the sixth escalation and freeze evidence
Record the person, local group, service identity, credential identifiers, synchronisation event, synthetic action, package scope and relevant clocks before changing state. Preserve broker, directory, archive, workflow and package audit logs under the applicable evidence procedure.
Block the faulty group-to-service delegation and suspend the credential if its callers cannot be separated. Keep the contractor’s approved current-project access only when the system can reliably distinguish it from the retired acquisition path.
- Authoritative identity and contract state.
- Group expansion and synchronisation records.
- Service credential, token and caller evidence.
- Package versions, hashes and actions.
- Containment time, scope, owner and reversal condition.
2. Separate identity recovery from polymer-package conclusions
The bypass proves that an unauthorised path could exercise export authority in the tested scope. It does not by itself prove that production data was exported, changed or used. Build four questions: capability, actual access, integrity and downstream decision use.
Answer each with its own evidence. Identity and synthetic tests establish capability; archive events establish access; hashes and version history support integrity; workflow and decision records support use.
3. Map the service-identity delegation graph
List every human, group, scheduler, workflow and application that can invoke the service identity. Record credential type, storage location, token lifetime, destination permissions and owner. Shared names hide multiple paths, so map actions rather than labels.
Find the earliest faulty edge. In the example, the nightly synchronisation restores a retired local group, which delegates to the export service. Removing only the service role leaves the source mapping ready to grant it again.
| Node or edge | Evidence | Recovery question |
|---|---|---|
| Source identity | Contract and role | Should authority exist? |
| Local group | Membership and expansion | Who inherits the path? |
| Service identity | Credential and callers | What can act? |
| Archive role | Effective permissions | Which actions are possible? |
| Package workflow | Audit and provenance | What was actually done? |
4. Revoke, rotate and invalidate safely
Disable the compromised service credential, revoke active sessions and rotate secrets or keys. Confirm propagation at every destination and cache. If the identity supports unaffected automation, provide a temporary least-privilege replacement with a distinct owner and narrow package scope.
Revocation is complete only when the old credential, derived tokens and delegated sessions fail. Test them deliberately in a harmless denied action and preserve the result.
5. Repair the earliest mapping and assign ownership
Remove the legacy synchronisation rule or correct its authoritative source. Reconcile downstream groups after the repair instead of relying on deletion that the next sync can reverse. Document who approves future mapping changes.
Give the service identity one accountable owner, a purpose statement, allowed callers, credential rotation schedule and expiry review. An unowned shared credential is a recurring control weakness even after technical cleanup.
6. Worked example: recover the archive export service
The team preserves the successful synthetic export trace, confirms that no production package export or write is recorded, and suspends the shared credential. It removes the nightly legacy group mapping, revokes refresh tokens and creates a temporary read-only automation identity for an unaffected retention job.
A package review compares versions, hashes and workflow actions for the two exposed historical packages. No modification or production export is supported by the evidence. The control failure remains material because the path could export; the scientific integrity claim remains unchanged because package-level evidence shows no alteration.
| Step | Evidence | Outcome |
|---|---|---|
| Contain | Delegation blocked and credential suspended | Prohibited action stops |
| Repair | Legacy sync mapping removed | Authority no longer regenerates |
| Reconcile | Groups, sessions and tokens cleared | Effective state matches model |
| Package review | No production export or change | No unsupported integrity claim |
| Temporary service | Read-only, owned and expiring | Unaffected work continues |
7. Replay lifecycle, synchronisation and token events
Test renewal, mover, expiry, termination, reactivation, nightly synchronisation, token refresh and retry. Include the exact event order that created the bypass. Verify both absence of retired authority and presence of approved current access.
Use synthetic packages and harmless denied actions. A re-release test should prove control without exposing real confidential material or granting broad permissions merely to observe failure.
8. Set sixth re-release gates
Re-release only when the authoritative source, synchronisation rule, local groups, service credentials, archive permissions and cached sessions converge on the approved model. The original bypass and adjacent paths must fail negative tests.
Package evidence must be complete enough for the claim being made. If logs cannot exclude production export, record that uncertainty and apply the appropriate package review rather than declaring continuity by assumption.
- Earliest faulty authority repaired.
- Old credentials and derived sessions fail.
- Delegation graph has complete owners and callers.
- Lifecycle and synchronisation negative tests pass.
- Package scope and evidence conclusion are recorded.
- Rollback, monitoring and next-escalation triggers are assigned.
9. Re-release in stages and watch recurrence
Restore the minimum service action first, using a new credential and narrow caller list. Expand only after effective-access and package-action monitoring remain inside the expected model. Keep the old identity disabled during the observation window.
Watch nested-group changes, service invocation, token refresh, archive export, package checkout and ownership drift. A clean login is not evidence that delegated automation is controlled.
10. Know the limits of logs and package reconstruction
Clock differences, shared accounts, retention gaps and incomplete export logging can weaken attribution. A stable hash supports no modification but cannot prove no read. State the strongest conclusion each evidence source supports.
A successful denial after repair proves current control in the tested path. It does not prove that every unregistered integration has been discovered; inventory coverage and owner attestation remain part of the claim.
11. Misconceptions, practical questions and transfer
Common mistakes include rotating a secret without repairing delegation, treating no hash change as no confidentiality event, deleting logs during cleanup and restoring the full service before negative tests. The repair is graph-based revocation and evidence-specific conclusions.
Can a replacement service identity be used before the investigation ends?
Yes, when it is separately owned, least-privilege, narrowly scoped and monitored. It must not recreate the uncertain delegation.
Does no recorded export prove no one viewed the package?
No. Export, read and modification are different actions, and the strength of the conclusion depends on logging coverage for each.
12. Changed-context evidence check and authoritative sources
Transfer the method to a vendor integration that uses short-lived workload identities instead of a shared key. Map issuer, audience, caller and token exchange; replace secret rotation with trust and policy repair while retaining evidence separation and negative replay.
ICH Q10 supports lifecycle monitoring, corrective action, change management and management review. NIST SP 800-53 Revision 5 provides flexible access-control, identity, audit and monitoring control families. Local architecture and package evidence determine the specific recovery and release gates.
Continue through the Gold Standard ecosystem
Return to the Polymer Science subject root, the Gold Standard of Education parent, or the How X Works hub.
Immediate predecessor: post-fifth-re-release surveillance and sixth-escalation gates · Earlier guide: fifth-escalation recovery and federated-identity quarantine · Polymer Science root
These routes are grouped by learning purpose: prerequisite model, immediate predecessor, and the wider transfer framework. They are not substitutes for the evidence and limits stated in this guide.