Notifications
Clear all
Topic starter
11/07/2026 8:42 pm
TL;DR: Automating SSL/TLS certificate renewal on A10 vThunder reduces manual renewal risk and shortens expiry exposure, but it also concentrates trust in ACME configuration, account binding, and update paths, according to Cybertrust Japan. The governance challenge is less about renewal mechanics and more about ensuring certificate lifecycle controls remain auditable and recoverable as environments scale.
NHIMG editorial — based on content published by Cybertrust Japan: SureHandsOn ACME and A10 vThunder certificate renewal automation
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: What breaks when certificate renewal automation is not governed properly?
A: Automation breaks down when ownership, binding, and deployment checks are missing.
Q: Why do certificates need identity governance if they are just part of infrastructure?
A: Certificates are machine identities because they authenticate systems and carry trust across service boundaries.
Q: How do security teams know if certificate automation is actually working?
A: It is working when renewals happen on schedule, the correct certificate is attached to the correct service, and operators can prove who owns the binding and the deployment path.
Practitioner guidance
- Define certificate ownership before enabling automation Assign a named owner, service context, and renewal responsibility for every certificate before enrolling it in ACME.
- Validate certificate-to-virtual-server bindings after renewal Check that each renewed certificate is attached to the intended virtual server, listener, or template and that the deployed chain matches the intended service path.
- Protect ACME account binding like a privileged secret Store external account binding material in a controlled secrets process, rotate it on a defined schedule, and revoke it when the associated service or team is retired.
What's in the full article
Cybertrust Japan's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact GUI steps for creating and enrolling ACME certificates in A10 vThunder.
- The specific renewal method selection between Before and Every, including the renewal trigger logic.
- Service-level configuration details for attaching renewed certificates to virtual servers.
- Examples of how the same workflow is adapted for BIG-IP and FortiGate environments.
👉 Read Cybertrust Japan's guide to automated certificate renewal on A10 vThunder →
Certificate renewal automation on vThunder: what should teams verify?
Explore further
11/07/2026 9:10 pm
Certificate automation is a non-human identity problem, not just an operations problem. A certificate can authenticate a service, a load balancer, or an integration path, which makes it a machine identity with a lifecycle. Once teams automate renewal, they must govern issuance authority, binding, revocation, and replacement with the same discipline they apply to other privileged identities. The practitioner conclusion is clear: certificate automation belongs inside identity governance, not outside it.
A question worth separating out:
Q: Who is accountable when an automated certificate renewal fails?
A: Accountability should sit with the team that owns the service, the enrollment policy, and the deployment pipeline, not with a generic infrastructure group alone. Certificate renewal crosses identity, operations, and application boundaries, so responsibility must be explicit. Frameworks such as NIST SP 800-53 and NIST CSF support that ownership model through access and configuration controls.
👉 Read our full editorial: Certificate renewal automation on A10 vThunder needs tighter governance
