How should teams govern TLS certificates for .onion services?

Why This Matters for Security Teams

TLS for .onion services is not just a transport detail. It is part of the service’s trust boundary, because the certificate binds an organisation-controlled service endpoint to a specific onion name and operational owner. If that binding is unclear, teams can end up with a service that is technically reachable but no longer clearly accountable. That creates audit gaps, renewal risk, and change-management blind spots, which are common failure modes in NHI programmes. NHI Mgmt Group’s lifecycle guidance and NIST Cybersecurity Framework 2.0 both point to the same operational principle: identity assets need ownership, review, and revocation, not just issuance. For .onion services, that means the certificate cannot be treated as a one-time setup item. It must be governed alongside the service itself, with clear control over who can request, approve, and renew it. In practice, many security teams encounter expired or misbound certificates only after an onion service change has already broken trust or exposed an ownership dispute.

How It Works in Practice

A workable model starts by treating the onion name, the certificate, and the service deployment as linked identity assets. Ownership should be explicit, ideally mapped to a service owner and an operational approver who can confirm the organisation is authorised to bind the onion name. That reduces the risk of shadow renewals, orphaned services, or certificates that outlive the team responsible for them. Most teams need three controls in parallel:

• Inventory: track every .onion service, its certificate, issuer, expiry, and owner in a system of record.
• Validation: require approval that the onion service still belongs to the organisation and the current application environment before renewal.
• Renewal: align certificate refresh with service change management so a rename, migration, or decommission event triggers review.

For evidence and lifecycle discipline, NHI Mgmt Group’s regulatory and audit perspective is useful because it frames machine identity as something auditors expect to be owned, traceable, and revocable. At the technical layer, the Tor Project’s certificate guidance should be used to understand how certificate presentation works for onion services, while policy teams can align the process to the NIST Zero Trust Architecture principle that trust should be continuously verified rather than assumed. The practical goal is simple: no certificate renewal should happen without confirming that the service, the owner, and the onion binding still match. These controls tend to break down in environments with frequent redeployments, outsourced administration, or split control between platform and application teams because ownership metadata falls out of sync with the live onion endpoint.

Common Variations and Edge Cases

Tighter certificate governance often increases administrative overhead, so organisations have to balance auditability against the speed of service change. That tradeoff is especially visible with .onion services because operational teams may rotate infrastructure more often than security teams rotate identity records. Current guidance suggests keeping the certificate lifecycle short and explicit, but there is no universal standard for how often to renew beyond the service’s risk profile and operational cadence. A few edge cases matter:

• If a .onion service is temporary, define a shorter approval window and a clear decommission date so the certificate does not become a lingering trust artifact.
• If multiple teams operate one onion service, use a named owner and a single renewal authority; shared responsibility without a single approver usually becomes no responsibility.
• If the service is part of a sensitive workflow, treat renewal as a change event and include rollback planning, because certificate changes can break reachability even when the application itself is unchanged.

NHIMG’s machine identity management research is relevant here because it shows how often organisations struggle with ownership and lifecycle discipline. The same pattern appears with onion certificates: when inventory is incomplete, renewal becomes reactive and accountability disappears. Best practice is evolving toward automated reminders, explicit approvers, and revocation on service retirement, but the control objective remains the same: the certificate should never outlive the authority to use it.

Related resources from NHI Mgmt Group

• How should security teams govern cryptographic keys and certificates across human and machine identities?
• How should security teams govern certificate trust for high-traffic services?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?