Ask that single sign on, multi factor authentication, unique initial passwords, security logs and an SBOM come standard, not as paid extras. CISA's Secure by Demand guide gives customers this list of questions. A vendor that treats them as add-ons is telling you something about its priorities.
The source of the list
CISA's Secure by Demand guide is written for software customers. Its questions fall into groups, and we have turned them into a short buyer's checklist. It was not written as a law, and your own risk decides what you require.
The checklist
| Area | Question |
|---|---|
| Authentication | Is standards based single sign on supported at no extra cost? |
| Authentication | Is multi factor authentication or a passkey option enabled by default, at no cost? |
| Defaults | Have default passwords been eliminated, or replaced with random, instance unique ones? |
| Vulnerability classes | Which classes of vulnerability has the vendor systematically removed, and what is the roadmap for the rest? |
| Evidence of intrusion | Are security logs part of the baseline product? |
| Supply chain | Does the vendor provide an SBOM in a standard, machine readable format that lists third party and open source components? |
| Disclosure | Does the vendor publish a vulnerability disclosure policy that authorizes testing, and file accurate CVE records? |
| Patching | Can customers install patches easily, with automatic updates available? |
| Commitment | Has the vendor made public security commitments and reports progress? |
Why these matter
Security features that cost extra go unused in practice. If single sign on or multi factor authentication needs a higher tier, some customers skip it, and the product is then exposed through weak accounts. The guide treats these as features customers should expect.
Default passwords are a classic problem, since an attacker can try the same known credentials against every installation. Random per instance passwords remove that shared weakness.
The question about vulnerability classes is the most demanding. It asks whether the vendor has designed out whole categories of flaws, for example through parameterized queries or memory safe languages, instead of patching each instance. The guide cites those examples.
How to use it
- Send the checklist before the demo, so answers are ready.
- Mark each answer yes, no or partial, with the evidence offered.
- For "no" answers, ask for a roadmap date and write it into the contract if you buy.
- Weight the list by use. A hosted product with user accounts cares most about authentication and logs. A server product you run cares about patching and the SBOM.
- Compare vendors on the same list, without naming winners in advance.
Pair this with questionnaire scoring, logging requirements and reading a vendor SBOM.
What this does not tell you
A yes on every line does not make a product safe. It shows a vendor has met a baseline you can check. You still need intake testing, monitoring and a patch plan.
Try it yourself
Click through it at your own pace, or open it full screen. See how controls map to a framework, a useful pattern when you turn a buyer checklist into evidence.
Quick check
Is multi factor authentication really a baseline ask?
CISA's guide asks whether it is enabled by default at no cost. Treat a paywall on it as a question for the vendor.
Does this checklist replace a security review?
No. It is a fast filter before deeper checks.
Safeguard's compliance and evidence automation and SBOM scanning help you apply this checklist across the products you buy.
Sources
Last reviewed: 19 October 2026.
