Demand evidence, not promises, when buying digital technology

A product demonstration can show that a feature exists. It does not prove how the product was developed, whether safe defaults are enabled, what components it contains, how updates are protected, or whether security will be maintained through the promised lifecycle.

What the joint procurement guidance says

Source fact: CISA and international partners encourage buyers to evaluate whether a digital product or service is secure before purchase and whether security will be maintained throughout its specified lifecycle. Security considerations integrated into procurement can support informed, risk-based decisions and reduce avoidable operating and incident costs.

Source fact: The co-sealed guidance addresses transparency and reporting, secure defaults, security requirements, supply-chain risk, open-source use, data sharing and sovereignty, development, manufacturer access, insider risk, open standards, connected systems, delivery integrity, updates, and post-purchase management.

Source fact: Manufacturer evidence can include attestations, independent assessment, testing, development practices, component transparency, vulnerability handling, digital signatures, and update-delivery controls. The publication states that it is not an exhaustive checklist and cannot guarantee a perfect procurement outcome.

Define evidence before accepting claims

DSE recommendation: document security, privacy, availability, data-location, integration, logging, support, update, recovery, accessibility, and end-of-life requirements before selecting a product. Scale questions and validation to the product’s business impact, privilege, data, connectivity, replaceability, and concentration risk.

1. Ask how secure development is governed and what evidence shows testing, component control, change approval, and vulnerability remediation operate.
2. Identify security features enabled by default, added cost or licensing, unsafe deviations, administrative access, and customer configuration duties.
3. Review open-source and third-party component governance, signed delivery and updates, support duration, end-of-life notice, and recovery options.
4. Determine manufacturer and subprocessor access, data use and location, incident notification, log availability, ownership changes, and exit treatment.
5. Test the claims that matter most in a bounded evaluation and record exceptions and compensating controls.

Distinguish kinds of assurance

DSE recommendation: label a statement accurately as a vendor claim, self-attestation, independent assessment, certification, document review, customer test, or observed production evidence. Each supports a different level and scope of confidence. Record residual risk and obtain acceptance from the correct authority rather than converting unanswered questions into assumed compliance.

After purchase, reassess material changes in product design, components, provider ownership, hosting, data use, vulnerabilities, support, update method, or access. Procurement evidence becomes stale when the product changes.

Applicability and limits

The full guidance is led by Australia’s ASD/ACSC and co-sealed by CISA and other national authorities. Jurisdiction, sector, contract, sanctions, export, sovereignty, and assurance requirements differ. An attestation or certification is not proof that a product is vulnerability-free, and lack of a particular certificate does not by itself establish insecurity.

Official reference

Choosing Secure and Verifiable Technologies — CISA’s official page for the co-sealed procurement guidance.