Cybersecurity Briefing — March 7, 2024
CISA’s Secure by Design pledge sets seven concrete outcomes—MFA defaults, secure configurations, unique credentials, memory safety roadmaps, VDP maturity, accessible telemetry, and incident transparency—that vendors must deliver by 2024, giving product leaders and buyers a shared blueprint for safer software.
Executive briefing: On 7 March 2024 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) unveiled the Secure by Design (SbD) pledge, a voluntary commitment for technology manufacturers to ship safer products by default. Initial signatories—including AWS, Cloudflare, Google, IBM, Microsoft, Okta, and Palo Alto Networks—agreed to deliver concrete improvements by year-end 2024 across seven focus areas: multi-factor authentication (MFA), default secure configuration, reduced default passwords, memory safety, vulnerability disclosure, secure telemetry, and incident response transparency.
The pledge reflects CISA’s push to rebalance security responsibility toward vendors. While voluntary, it establishes measurable outcomes that enterprise customers can use to assess supplier maturity. Organisations building or procuring software should incorporate SbD principles into product roadmaps, procurement criteria, and compliance programmes.
Pledge commitments
Participants commit to the following outcomes:
- MFA enablement: Ensure MFA is either on by default or easily adoptable for privileged access, with public progress metrics.
- Secure default configuration: Ship products with security features (logging, encryption, least privilege) enabled out of the box, minimising reliance on customer hardening guides.
- Eliminate default passwords: Remove vendor-supplied default credentials, implement unique credentials per device, and support modern authentication.
- Memory safety roadmap: Publish plans to transition to memory-safe languages or mitigations, with milestones and metrics.
- Vulnerability disclosure policies (VDPs): Maintain accessible VDPs and commit to remediation timelines.
- Secure telemetry: Provide customers with logging needed to detect attacks without additional cost, including log retention guidance.
- Incident response transparency: Share root-cause analyses and lessons learned from significant incidents to drive sector-wide improvement.
Signatories will report progress to CISA within one year. CISA plans to publish aggregated updates and promote additional commitments (e.g., secure update mechanisms, AI safety).
Implications for software manufacturers
Product leaders should treat the pledge as a blueprint for modern secure development. Actions include:
- Incorporating SbD requirements into product requirement documents (PRDs), release criteria, and go/no-go decisions.
- Establishing executive sponsorship (e.g., CTO, CISO, CPO) to oversee pledge progress and resource allocation.
- Creating cross-functional workstreams covering authentication, secure defaults, memory safety, telemetry, and incident response.
- Aligning SbD initiatives with ISO/IEC 27001, SOC 2, FedRAMP, and upcoming NIST Secure Software Development Framework (SSDF) attestations mandated by U.S. federal procurement rules.
Implementation roadmap
- Baseline assessment (Q1 2024): Inventory products and services, evaluate current MFA adoption rates, default settings, memory-safe code percentages, logging capabilities, and VDP maturity.
- Roadmap development (Q2 2024): Define workstreams with milestones and budget. Prioritise high-risk products (identity providers, networking gear, cloud platforms) and align with planned releases.
- Execution (Q3–Q4 2024): Implement product changes—enable MFA by default, update installers to disable insecure protocols, transition components to Rust or memory-safe libraries, release updated logging features, and refresh VDPs.
- Reporting (Q4 2024–Q1 2025): Publish transparency reports summarising progress, metrics, and residual challenges. Prepare documentation for CISA submissions and customer communications.
- Continuous improvement: Integrate SbD metrics into product operations dashboards, release reviews, and customer advisory boards.
Governance and metrics
Boards should receive quarterly updates on SbD progress, including MFA adoption percentages, number of products with secure defaults, vulnerability remediation times, and share of memory-safe code. Tie executive compensation or OKRs to SbD milestones to maintain accountability. Audit teams should verify evidence supporting public commitments.
Memory safety transition
Moving away from memory-unsafe languages (C/C++) requires multi-year planning. Organisations should:
- Identify components suitable for refactoring to Rust, Go, or memory-safe C++ alternatives.
- Invest in developer training and tooling (fuzzing, sanitizers) to mitigate vulnerabilities in existing code.
- Set KPIs—percentage of new code in memory-safe languages, number of vulnerabilities per 10,000 lines of code, reduction in high-severity memory corruption flaws.
Secure telemetry delivery
Vendors should ensure customers receive critical logs (authentication, admin actions, configuration changes) without premium licensing. Provide APIs and SIEM integrations, document retention guidance, and ensure logs are tamper-evident. Consider offering security configuration baselines and automated alerting for suspicious activity.
Procurement and customer alignment
Enterprise buyers should update procurement questionnaires and contracts to reference the SbD pledge. Request proof of MFA defaults, memory safety roadmaps, and log access. Integrate SbD criteria into vendor risk assessments, especially for critical SaaS, identity, and infrastructure providers.
Government buyers can align the pledge with Executive Order 14028 software supply chain requirements, NIST SSDF attestation, and CISA’s forthcoming secure software self-attestation form. Documentation supporting SbD commitments can satisfy procurement audits.
Incident transparency
Vendors must prepare templates and processes to share root-cause analyses within 90 days of major incidents. Establish legal and communications protocols to balance transparency with liability concerns. Coordinate with customers to share indicators of compromise, mitigation guidance, and patch timelines.
Vulnerability disclosure and support
Enhance VDPs with clear scope, submission channels, and service-level objectives (SLOs). Provide researchers with public PGP keys, safe harbour language, and coordinated disclosure processes. Track remediation metrics and publish annual vulnerability reports.
Regulatory landscape
The pledge complements legislative efforts such as the proposed U.S. Cybersecurity Safety Review Board recommendations, FTC software liability discussions, and EU Cyber Resilience Act obligations. Meeting SbD outcomes now can reduce future compliance burdens and demonstrate good-faith efforts if regulatory enforcement follows.
Customer communication
Inform customers about planned changes—default MFA enforcement, configuration updates, new logging exports—and provide migration guides. Offer opt-in periods and support channels to manage user impact. Highlight how SbD initiatives reduce risk and align with customer compliance frameworks (PCI DSS, HIPAA, SOC 2).
Internal audit and assurance
Audit teams should evaluate control design and operating effectiveness for SbD commitments. Sample activities include verifying MFA defaults across representative tenant environments, reviewing change management records for secure configuration releases, and testing vulnerability disclosure response times. Document findings and remediation plans to support external attestations.
Insurance and contractual leverage
Cyber insurers increasingly evaluate vendor security posture. Demonstrable progress on SbD outcomes can improve insurability and reduce premiums. Update customer contracts to reflect SbD improvements and offer security addenda showing default protections, which may reduce liability exposure.
Ecosystem collaboration
Coordinate with open-source communities to incorporate SbD practices, such as adopting memory-safe languages in upstream projects and publishing secure configuration baselines. Participate in CISA-hosted working groups to share implementation patterns and challenges.
Customer adoption support
Provide migration tools, API endpoints, and automation scripts to help customers adopt new security defaults without service disruption. Offer professional services or partner enablement to accelerate rollout. Track customer adoption metrics to ensure new features reduce risk in practice.
Future outlook
CISA intends to expand the pledge to additional vendors and may introduce scorecards or public reporting. Organisations should expect increased scrutiny from insurers, auditors, and regulators regarding SbD outcomes. Continue to monitor CISA publications, including case studies and technical guidance, to refine implementation.
Sources
- CISA announcement of the Secure by Design pledge
- White House fact sheet on Secure by Design commitments
- CISA Secure by Design resources
Zeph Tech guides software manufacturers and enterprise buyers through Secure by Design adoption, roadmap execution, and transparent reporting.
Continue in the Cybersecurity pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Cybersecurity Operations Playbook — Zeph Tech
Use Zeph Tech research to align NIST CSF 2.0, CISA KEV deadlines, and sector mandates across threat intelligence, exposure management, and incident response teams.