When Revocation Does Not End Access

What happens when the old credentials stop working, but the application can still create new ones? I investigate this recovery failure through a small running system: an issuer, a protected resource and a separate observer. Across 48 distinct repair-and-renewal schedules, 20 retain access even though every original credential is rejected. Each schedule is repeated three times. The failure depends on the order in which authority is removed and its source is stopped. I express that dependency as a renewal graph and prove a conditional repair-order rule, checked against 98,697 graph-order pairs. A second failure survives an otherwise effective provisioning barrier: work accepted before containment creates new credentials after revocation. An executed walkthrough compares leaving that work pending, cancelling it and rejecting it at commit using an issuance epoch. The last two prevent reopening in the tested sequence; a positive control confirms that new work can succeed after service resumes. Equifax, Exchange and MOVEit establish the need to examine application, identity and data boundaries separately. The contribution is a reproducible recovery test that follows replacement credentials and pending issuance through to the protected operation, with explicit conditions for what its result establishes.