Secure by design for sellers: what changes in a product conversation

A customer asks, “Why do we have to configure so much just to make the product safe?”

That question sits at the heart of secure-by-design thinking.

CISA described an updated secure-by-design approach in material released in October 2023 and explained it publicly on 16 November 2023. The approach centres on three principles: manufacturers should take ownership of customer security outcomes, embrace radical transparency and accountability, and lead security from the top of the organisation. [Source: CISA, 16 November 2023.]

For sellers, this is not a slogan to add to a slide. It changes the questions customers may ask about the product itself.

A weak sales conversation treats security as implementation work.

The product is sold first, then the customer is told to harden it, find the right settings, buy another service or discover which logs are available.

Secure-by-design thinking pushes responsibility earlier.

Customers may ask which protections are built in, which safer settings are enabled by default, how vulnerabilities are handled and what the supplier communicates when something goes wrong.

The seller should be ready to route those questions to product evidence.

A capability can exist without being enabled.

That difference matters commercially.

If a product supports stronger authentication but ships with a weaker configuration, the buyer may have to plan deployment work before the control exists in practice. If a security feature requires another entitlement or customer action, that dependency should be visible.

Do not say “the product is secure by default” unless the approved evidence defines what that means for the exact version and configuration being sold.

A feature list is not a default-state description.

CISA's secure-by-design framing includes radical transparency and accountability. [Source: CISA, 16 November 2023.]

For a seller, transparency is not the same as publishing every internal detail.

It means the organisation should be able to explain meaningful product-security facts honestly: supported versions, known limitations, remediation paths, security contacts, vulnerability handling and customer responsibilities where those are documented.

This can feel uncomfortable because sales teams are trained to remove friction.

In security deals, hiding uncertainty usually creates more friction later.

One of the easiest overclaims in cybersecurity is not saying too much about the product. It is asking the customer to carry a risk the supplier's own design should address.

A customer can still own configuration, identity, data classification or operational decisions.

Secure by design does not eliminate shared responsibility.

It does create a useful question: is this genuinely a customer decision, or are we describing a product weakness as though the customer simply needs to operate better?

The answer should come from the product and service model, not from sales instinct.

Secure-by-design questions can appear in security questionnaires, contract negotiations and technical evaluations.

A seller should know where the evidence lives.

Which document describes default settings? Which team owns vulnerability statements? Is there an approved description of logging? Is the requested security behaviour part of the product, a managed service or the customer's environment?

This makes procurement faster because answers can be traced instead of improvised.

It also gives channel and services partners a safer boundary. A partner can explain an approved product-security position, but it should not create a stronger claim simply because the customer asks for certainty. If the evidence owner has not confirmed the statement, the right action is escalation, not invention.

Avoid broad claims such as “secure out of the box” unless the evidence supports the exact scope.

Avoid implying that a customer is protected simply because a feature exists.

Avoid telling the buyer that security is entirely their responsibility when the supplier owns part of the product outcome.

And avoid using “secure by design” as a substitute for explaining the actual control.

The useful message is specific.

State the security outcome the product was designed to support. Explain what is enabled by default. Name the customer-controlled settings. Show the evidence that supports the claim. Identify the owner for anything still open.

That is how secure-by-design thinking becomes commercially credible rather than another marketing phrase.

Relevant programme: Develop product-security and evidence-boundary judgment through the ASTRA Cybersecurity Sales Specialist programme: https://www.astraready.com/programmes/