Start free trial

By Yair Knijn · July 17, 2025

Why the deal stalled on a vendor security questionnaire about certificate lifecycle

If you run security at a company that sells into the enterprise, your job has quietly split in two. Half is defending your own perimeter. The other half, the part nobody put in a budget, is proving to someone else's third-party risk team that the perimeter is real. Certificate lifecycle lives entirely in that second half, which is exactly why it stays underfunded. No internal user files a ticket when the inventory is a spreadsheet. The pain surfaces later, in a stranger's questionnaire, attached to a deal you meant to close this quarter.

The trap is treating certificate management as an operations detail that sits beneath the deal. To the buyer it is a line item in their supply-chain risk model, and a thin answer there reads as an unmanaged attack surface you are about to bolt onto their environment.

What modern vendor security questionnaires ask about PKI

A current SIG or CAIQ-style questionnaire will not accept "we use TLS 1.2+ and AES-256" as a complete answer to the cryptography section anymore. Reviewers want the operating evidence behind the claim. You should expect pointed questions: a full inventory of public and internal certificates with named owners, the renewal method and whether it runs without a person, where private keys are generated and stored and whether an HSM or KMS guards them, and your mean time to rotate after a compromise or a forced revocation.

Since PCI DSS v4.0 became mandatory on 2025-03-31, the expectation of dated evidence has spread well past cardholder data. Buyers now ask vendors to show the report rather than assert the control, and an undated, hand-maintained certificate list is usually the first thing to fail that test.

Why "we renew them when alerts fire" fails due diligence

A risk analyst reads that sentence literally. "When alerts fire" tells them you only know about the certificates your monitoring already happens to watch, which leaves out the shadow ones an attacker goes for first. It also pins your control to a human noticing an email. The reviewer maps that straight to a finding: detective control only, no preventive control, no evidence it operated across the audit period.

And the damage is not a gentle "needs improvement." On a high-risk vendor, an open cryptography gap with no compensating control sends the deal back through legal and procurement. The technical fix is maybe a week of work. The deal slips a quarter while you assemble documentation you should have had on day one.

Mapping your controls to ISO 27001 and SOC 2 cryptography clauses

Reviewers are not inventing their questions. They translate framework clauses, so it pays to answer in the same language. ISO/IEC 27001:2022 Annex A control A.8.24 ("Use of cryptography") expects a documented policy covering the key lifecycle: generation, storage, rotation, and revocation. SOC 2 leans on the relevant Common Criteria for confidentiality and change management, where the auditor tests whether the control actually ran, not whether a policy PDF exists.

Take each questionnaire line, point it at the control it implements, and attach the proof:

Turning certificate automation into a sales accelerator, not a blocker

The same artifacts that satisfy an auditor also shorten the sales cycle, because the questionnaire turns into a copy-paste exercise instead of a fire drill. When inventory, renewal logs, and key custody come out of the system on demand, your team clears the cryptography section in an afternoon with evidence attached, and the buyer passes you on the first read. That is the gap between being the easy vendor to approve and being the contract that sits in review.

Automate Certificates gives each customer Environment a continuously discovered inventory, automated ACME renewal with full event logs, and key-custody records that line up with the exact clauses a questionnaire cites, so the artifacts already exist before the buyer asks. See how the controls map on the security page.