In autocert's Manager, there are three fields for which the zero value is unsafe:

Email: The zero value means "provide no email." This is unsafe because the CA can't reach the user if their client is being blocked, or if APIs are changing such that their renewals will fail soon. It also means the user can't receive renewal emails. The ACME spec and Let's Encrypt allow for registering with no email, which should be a supported use case but not the default.

The Certbot project has had good success by requiring one of --email or --register-unsafely-without-email. In autocert, this could take the form of a sentinel value autocert.UnsafeRegisterWithoutEmail that indicates to Manager that the user really does want to register without email.

HostPolicy: The zero value means "TLS handshakes can trigger a certificate request for any hostname." This is unsafe because anyone on the internet can cause a server running autocert to send many requests to a CA, possibly exceeding its rate limits and/or getting blocked. The documentation says this but I suspect many people still run with this policy.

A safe alternative would be to consider nil equivalent to "reject all hosts," and offer an explicit UnsafeIssueForAnyHost HostPolicy. A couple of other HostPolicies that might be popular and provide lower risk: IssueForSubdomains, which would contain a list of domains and accept issuance requests for any of those domains' subdomains; and IssueForResolvedDomains, which would resolve a domain and attempt to issue only on success (or only if it resolves to a specific set of IP addresses).

Cache: The zero value means "no cache." This is unsafe because it's common for servers to wind up in a crash loop. If there is no cache, crash-looping servers will not have their certificates ready on startup, and will send excessive traffic to their CA. This is behavior we've seen from other clients in the past, like cert-manager.