Botdoc signed the CISA Secure by Design Pledge on April 23, 2025. More than a year in, this post is our public progress report: what was already true when we signed, what we have shipped since, and what we are still working on.
The pledge is a voluntary commitment coordinated by the Cybersecurity and Infrastructure Security Agency, the U.S. government's national cyber defense agency. Signers commit to making measurable, publicly documented progress toward seven security goals covering how software is built: multi-factor authentication, default passwords, vulnerability classes, patch adoption, vulnerability disclosure, CVE transparency, and intrusion evidence.
We signed because the pledge describes the way Botdoc was built from the beginning. Our platform moves sensitive documents and data for banks, hospitals, schools, and dealerships. When that is your job, security cannot be a feature you add later. It has to be the architecture.
Here is where we stand, goal by goal.
Goal 1: Multi-factor authentication
The most important thing about MFA at Botdoc is where it is not needed. For the consumers our customers serve, the transport requires no accounts, no passwords, and no MFA, because there is nothing to log into. You cannot phish credentials that never exist. That is not a compliance workaround; it is the architecture, and it is the reason the pledge's authentication goal is smaller for us than for most signers.
Where credentials do exist, MFA is mandatory. It is enforced across Botdoc's production systems, internal systems, and employee accounts, mandated in our Information Security Policy, and verified in our annual SOC 2 Type 2 audit, which returned a clean, unqualified opinion for the full 2025 calendar year. Where a customer-facing portion of a product requires a login, MFA applies there too.
Goal 2: Default passwords
In August 2025, four months after signing the pledge, we added a Default Manufacturer Credential Management section to our Information Security Policy that explicitly prohibits default credentials in production systems. Every deployed system ships with unique, managed credentials. This is the kind of concrete, dated change the pledge exists to drive.
We think about this goal beyond our own infrastructure, because our products often replace workflows where default credentials are endemic. The clearest example is the office multi-function printer. Most MFPs ship with default admin passwords, and their scan-to-email function stores an SMTP username and password in the device configuration where anyone with the default admin login can read it. When we built Secure MFP, our secure transport product for print and scan workflows, we designed the credential problem out: nothing sensitive lives on the device, so there is nothing for a default password to expose.
Goal 3: Reducing entire classes of vulnerabilities
This is the goal we care about most, because it is the reason Botdoc exists.
Most of the industry reduces vulnerabilities one patch at a time. Our approach is to remove the conditions that entire classes of vulnerabilities need in order to exist. Botdoc is Secure Digital Transport: a stateless, disposable transport layer, encrypted from pickup to delivery, where connections between endpoints are dynamic, transactions evaporate after delivery, and no login is ever required of the receiving party.
That architecture eliminates classes, not instances:
- Credential-theft attacks against end users cannot happen where no end-user credentials exist.
- Breaches of stored documents are addressed by architecture: there is no long-term document repository to breach. The single encrypted delivery copy is purged automatically after the retention window, leaving a single chain of custody instead of the five or more residual copies legacy tools scatter across mailboxes, servers, and devices.
- The high-value-target problem disappears when there is no centralized data store to raid and no master controller of encryption keys.
- Interception in transit is addressed by encrypting every transaction with TLS in transit and AES-256 at rest, from pickup to delivery.
These are not abstract principles. They ship in products today. Secure MFP applies exactly this architecture to one of the most overlooked attack surfaces in any regulated office, the scan-to-email workflow on the multi-function printer, replacing stored credentials and unencrypted attachments with disposable, encrypted transport. You can see how the same design decisions play out device by device at securemfp.io.
Architecture does not excuse us from vigilance on the code we ship. Our Application Security Policy mandates secure development practices, and we run continuous vulnerability scanning through independent platforms on a weekly cadence, with findings triaged and remediated under documented timelines.
Goal 5: Vulnerability Disclosure Policy
Today, as part of this pledge, we published Botdoc's public Vulnerability Disclosure Policy.
It authorizes good-faith security research on our products, commits us to not pursuing legal action against researchers who follow the policy, provides a clear reporting channel, and supports coordinated public disclosure. Security researchers make platforms like ours stronger, and we would rather hear from them directly, quickly, and on the record.
Goal 7: Evidence of intrusions
Customers cannot respond to what they cannot see. Botdoc maintains audit controls, logging, and monitoring across the platform, documented in our HIPAA Security Rule reporting and tested in our annual information security audits. Because every transaction is discrete and disposable, each one produces a clean, singular audit trail: who sent, who received, when, and through what channel, without the ambiguity of shared mailboxes and forwarded attachments.
Goals 4 and 6: The honest section
Two goals are works in progress, and the pledge asks signers to say so plainly. On patch adoption (Goal 4), our SDLC and patch management procedures govern our own platform, and because Botdoc is delivered as a service, customers receive updates without an adoption step. We are working on how to demonstrate that measurably rather than just asserting it. On CVE transparency (Goal 6), our transport-only architecture keeps our CVE surface small, and we commit to timely, complete CVE records, with accurate CWE and CPE fields, for any critical or high-impact vulnerability ever found in our products. Pledging this signals confidence in our posture, and we would rather own that conversation than avoid it.
Why a company our size signs a federal pledge
The Secure by Design Pledge is voluntary, and CISA does not verify or endorse signers. So why do it?
Because trust is the product. A defaulted mortgage borrower, a trauma center records clerk, and a dealership F&I manager all need the same thing from us: transport they do not have to think about. The pledge gives us a public, dated, goal-by-goal way to show our work, alongside some of the largest software companies in the world. We built Botdoc so that entire categories of attack have nothing to attach to. Publishing our progress is how we prove we are staying that way.
Our progress reports will continue as we close the remaining goals. The receipts, our SOC 2 Type 2 report and full due-diligence portfolio, are available to customers and partners on request.
Karl Falk is the founder and CEO of Botdoc, the company defining the Secure Digital Transport (SDT) category.