Web Key Directory, or WKD, is a standard way to publish OpenPGP public keys on a domain so they can be discovered from an email address. It uses a well-known HTTPS location under the domain, letting clients fetch a matching key and reduce manual key exchange errors.
How Web Key Directory works
WKD makes OpenPGP key discovery much more reliable by giving clients a domain-based lookup path tied to an email address. Instead of relying on manual key sharing or ad hoc keyserver searches, the publishing domain provides a predictable HTTPS location for the public key.
This matters because the directory structure is part of the trust and usability model, not just a convenience feature. When users and mail clients can retrieve the right key automatically from the sender's domain, the chance of encrypting to the wrong key, skipping encryption, or accepting stale key material drops significantly.
Why WKD improves email key discovery
WKD sits at the intersection of email identity, public-key distribution, and transport security. The point is not to replace OpenPGP, but to reduce the operational friction that often causes teams to avoid encryption or to exchange keys out of band in ways that are easy to get wrong.
Because the published key is fetched from a well-known HTTPS location under the domain, clients can verify a domain-controlled source before using the key. That makes WKD especially useful where the organisation wants a low-friction path for recipient key lookup without depending on a central directory service or a separate enrollment workflow.
What WKD does and does not solve
WKD solves discovery, not full trust management. It helps a client find a matching public key for an email address, but it does not by itself prove that the key is the right one for every policy, workflow, or threat model. Organisations still need to decide how keys are generated, revoked, rotated, archived, and recovered.
It also does not remove the need to validate the broader email security design. If an organisation supports both encryption and signing, it should ensure the published key supports the intended use, that published material is kept current, and that clients know how to handle stale or replaced keys.
Where WKD fits in an organisation
WKD is most useful when the organisation wants domain-controlled key publication to support routine encrypted email between known parties. It is a practical building block for reducing manual exchange errors, but it only works well when the domain ownership, DNS, HTTPS hosting, and key lifecycle are all kept consistent.
For broader deployment guidance around OpenPGP and S/MIME, including enterprise key handling and selection trade-offs, see OpenPGP and S/MIME Email Encryption Guide. For the trust and access patterns that arise when keys are published from a domain and then verified by software, Web Bot Auth and HTTP Message Signatures for Agents is a useful adjacent reference on directory-backed cryptographic verification.
Risk and Threat Considerations
WKD reduces human error, but it also creates a small, high-value trust surface around domain hosting and key publication. If that surface is misconfigured, stale, or tampered with, clients may retrieve the wrong public key, fail to encrypt, or trust an outdated key after a rotation event.
Failure mechanism: Attackers or misconfigurations can exploit weak HTTPS hosting, incorrect publishing, or stale records to steer clients toward invalid or attacker-controlled key material.
Impact: The result can be failed confidentiality, message interception opportunities, or persistent delivery of encrypted mail to a key that no longer reflects the intended recipient.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | WKD publishes OpenPGP keys, so key lifecycle and rotation are central to the term. |
| Recommendation — Manage WKD-published keys with defined generation, rotation, revocation, and replacement procedures. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | WKD distributes public keys that support authentication and trust decisions for email. |
| IA-9 — Service Identification and Authentication | WKD is a machine-readable trust mechanism used by clients to fetch and validate keys. | |
| Recommendation — Control published keys with lifecycle rules for issuance, rotation, revocation, and secure storage. Use domain-controlled key publication to support authenticated retrieval of public keys. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | WKD affects who can rely on published key material and how access trust is enforced. |
| Recommendation — Govern publishing and retrieval permissions for key material under an access-control policy. | ||
| CIS Controls v8 | CIS-5 — Account Management | WKD depends on accurate account-to-key mapping across the email identity lifecycle. |
| Recommendation — Keep account-to-key mappings current so published keys match active mail identities. | ||
Practitioner Guidance
Why practitioners should care: WKD only delivers value when its publication path, DNS, HTTPS, and key lifecycle are aligned. Treat the published key as operational identity material, because stale or unmanaged keys can quietly break encryption or trust expectations.
Common misunderstanding: Teams sometimes assume that publishing a WKD record once is enough. In practice, the directory has to track key rollover and revocation just as carefully as any other externally consumed trust anchor.
Practitioner takeaway: Use WKD as a controlled discovery mechanism, not as a substitute for key governance, review, and rotation discipline.
Related resources from NHI Mgmt Group
- Why do small cache key transformation bugs create outsized risk for web applications?
- What are the signs that cache key normalization is failing in a web application?
- How should security teams scale directory brute-forcing across many web applications without losing review quality?
- Why do modern web stacks make directory brute-forcing less reliable than simple status-code checks?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org