Notifications
Clear all
Topic starter
25/06/2026 2:44 pm
TL;DR: Certificate Signing Requests standardise key sizes, algorithms, and identity fields across issuance, renewal, migration, and device provisioning, according to Keyfactor. Treating CSR creation as a policy gate, not a clerical step, is what keeps certificate estates auditable and reduces outage and compliance risk.
NHIMG editorial — based on content published by Keyfactor: The Right Time to Generate a CSR: A Guide to Smarter Certificate Management
Questions worth separating out
Q: How should teams govern certificate requests across different systems?
A: They should treat CSR creation as a policy enforcement point, not a request form.
Q: When does certificate renewal require a new CSR instead of reusing the old one?
A: A new CSR is needed whenever a new key pair must be created, such as when keys are rotated, compromised, or tied to a cryptographic upgrade.
Q: What do security teams get wrong about automated certificate management?
A: They often automate issuance without automating governance.
Practitioner guidance
- Standardise CSR templates across all teams Define approved values for SANs, algorithms, key sizes, and organisational fields, then block ad hoc request formats from production issuance paths.
- Tie CSR generation to certificate inventory Track every issued certificate and its renewal date so new CSRs are generated before expiry, not during an outage scramble.
- Require new keys after exposure or policy change Treat key compromise, algorithm upgrades, and CA migrations as triggers for fresh key pairs rather than renewal of existing material.
What's in the full article
Keyfactor's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for when to generate a CSR across issuance, renewal, CA migration, DevOps, and IoT scenarios.
- Practical examples of CSR fields such as SANs, key usage, and algorithm settings that affect certificate validity.
- Pitfall-to-solution guidance for malformed requests, insecure key storage, and manual renewal delays.
- Automation examples using ACME and EST for short-lived certificates in machine-paced environments.
👉 Read Keyfactor's guide on when to generate a CSR →
Certificate signing requests: where certificate governance succeeds or fails?
Explore further
25/06/2026 3:51 pm
CSR generation is the certificate governance choke point, not a back-office task. The article correctly places policy enforcement at request time, because the CSR determines whether key size, algorithms, and identity fields are aligned before trust is granted. That is the same control logic NHI programmes rely on for workload identities and other certificate-backed actors. The implication is simple: if the request is uncontrolled, the certificate lifecycle is already drifting.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: How do organisations keep certificates auditable during CA or infrastructure migrations?
A: They should inventory every existing certificate before the migration, then require fresh CSR-based reissuance where the trust hierarchy changes. That gives teams a clean record of what was re-established, what was retired, and which assets still need remediation.
👉 Read our full editorial: CSR generation is the control point for certificate governance
