Offboarding an mTLS client takes more than deleting its certificate file
A device is retired and its certificate file is deleted from the device. Is access removed? That depends on copies of the key, the server’s certificate checks, application permissions and existing sessions. An offboardin
A device is retired and its certificate file is deleted from the device. Is access removed? That depends on copies of the key, the server’s certificate checks, application permissions and existing sessions. An offboarding checklist should follow those separate paths.
Offboarding design; no revocation or access test was performed.
Identify the credential and the permissions
Record the client certificate identity, issuer, serial number or fingerprint, associated account and allowed operations. Do not place private key material in the ticket. A certificate authenticates a credential; the application still needs a policy that maps it to access.
This distinction gives you two different questions: can the client authenticate, and what can an authenticated client do? Removing a file answers neither question for other copies.
Check how the server rejects retired credentials
Depending on the system, rejection may involve revocation checking, a local deny list, short certificate lifetimes or an application-level account policy. Determine what is actually implemented. Do not assume that publishing a CRL makes every client or server consume it immediately.
Document the verifier, its update behavior and the maximum expected delay. Unknown behavior should remain unknown until tested.
Include sessions and duplicate installations
A credential may have been installed on more than one device. An existing application session may also outlive the TLS connection that created it. Identify where access persists and which component can terminate it.
Use an authorized test account to verify the expected denial. A successful administrative click is useful evidence of the requested change, but it is not the same as observing access denied at the service boundary.
Close with a bounded result
A practical record includes credential identifier, policy changed, effective time, test endpoint, observed outcome and untested paths. Explain whether the test used a fresh connection, an existing session or both.
This makes offboarding auditable without claiming instant global revocation. The checklist is a design aid; it does not establish that your particular mTLS service checks revocation or invalidates sessions automatically.
Primary sources
Further reading on PKI Channel
The following Japanese-language guides add diagrams and operational detail to the questions discussed above.
AI was used for research assistance, writing and illustration. Examples and checklists are explanatory, not reported lab results.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.