mkcert is a developer tool that creates locally trusted certificates by generating a local certificate authority and adding it to the developer machine's trust store. It simplifies HTTPS for local testing, but teams should keep those certificates off production systems and avoid letting local trust material leak into shared environments.
How mkcert fits into local HTTPS development
mkcert works by standing up a local certificate authority that your own development machine trusts, then using that CA to issue certificates for local hostnames. That lets browsers and clients accept HTTPS on localhost or internal test names without the usual warning prompts. The important distinction is that the trust is intentionally local and developer-managed, not a general-purpose production trust anchor.
Because it installs trust material into the local trust store, mkcert is best understood as a convenience layer for development ergonomics, not as a replacement for enterprise PKI. It reduces friction for testing secure cookies, redirect handling, service-to-service calls and browser features that expect HTTPS, but it does not change the need to manage trust boundaries carefully.
In practice, the tool creates a private CA key and certificate on the developer workstation, adds the CA to the local trust store, and then signs leaf certificates for the requested local names. That model is useful because the browser trusts the local CA chain, but the same model also means the CA material becomes sensitive and should be handled like other high-value cryptographic material.
Why local trust material must stay out of production
mkcert is deliberately scoped to a developer environment, so the trust anchor it creates should not be copied into shared staging, production, or unmanaged test systems. If local trust material escapes its intended boundary, systems may start accepting certificates that were only meant to prove local development identity, which weakens the separation between safe test traffic and real operational traffic.
The same caution applies to exported certificates, copied private keys, or shared browser trust stores. A developer CA that is convenient on one workstation can become an implicit trust root elsewhere, which makes certificate misuse or accidental trust expansion much harder to notice. That is why teams should treat mkcert output as ephemeral development infrastructure rather than reusable security tooling.
What mkcert does not solve on its own
mkcert makes local TLS usable, but it does not manage certificate lifecycle for an organisation, enforce issuance policy, or protect against misuse once the certificates are outside the intended scope. It also does not replace hostname hygiene, application configuration review, or secrets handling for the underlying CA private key. If the CA key is compromised, the trust it created on that workstation is no longer trustworthy.
It is also not a substitute for production-grade identity and certificate management. Teams that rely on it for local testing still need a separate approach for issuance, rotation, revocation, storage, and access control in non-development environments. The value of mkcert is speed and local convenience, not lifecycle governance.
Risk and Threat Considerations
Local certificate authorities are attractive because they remove browser warnings, but that same convenience can hide boundary mistakes. The main risk is trust expansion, where a certificate or private key intended for one workstation, one project, or one developer gets reused more broadly than intended.
Failure mechanism: A locally trusted CA or its private key is exported, copied, or retained too long, then becomes a trust root in environments where it was never meant to exist. That can allow unintended certificate acceptance, mask configuration errors, or make it harder to detect when test material has crossed into shared infrastructure.
Impact: Developers may miss misconfigurations, test traffic may be mistaken for trusted traffic, and a leaked CA key can undermine confidence in any certificate chain signed by that CA. The practical consequence is not just warning suppression, but reduced assurance about what is genuinely trusted and where that trust applies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-53 Rev 5 | IA-5 — Authenticator Management | mkcert creates and uses certificate material that must be protected and rotated. |
| IA-9 — Service Identification and Authentication | mkcert issues certificates that authenticate local services and endpoints in test setups. | |
| Recommendation — Manage certificate material with controlled issuance, rotation, and revocation. Use distinct service authentication material for development and keep it scoped to the intended environment. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Local trust stores and CA keys require controlled access to prevent trust leakage. |
| Recommendation — Restrict access to developer trust material and prevent reuse in shared systems. | ||
| CIS Controls v8 | CIS-5 — Account Management | Developer trust material should be assigned and removed with clear ownership and lifecycle control. |
| Recommendation — Track ownership of developer certificate material and remove it when it is no longer needed. | ||
Practitioner Guidance
What to verify: Confirm that the mkcert CA exists only on approved developer machines and that its trust is not imported into shared images, CI runners, or production endpoints. If the same leaf certificate or CA material is visible outside the intended workstation, treat that as a boundary failure rather than a minor hygiene issue.
Decision rule: If you need HTTPS for local development, use mkcert for that workstation only; if you need repeatable non-local issuance, move to a managed certificate process with explicit ownership, rotation, and revocation. Do not let convenience tooling become the implicit certificate system for environments that outlive the developer session.
Practitioner takeaway: mkcert is a local trust bootstrapper, not a certificate governance model, so its value depends on keeping the generated CA and issued certificates tightly scoped to development and out of shared trust paths.
Related resources from NHI Mgmt Group
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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org