Secure by Design

Multi-factor authentication is required for every Standard Works user, not offered as an opt-in. Users authenticate with a password plus a second factor: either a one-time code sent to a verified phone number or a code from an authenticator app (TOTP).

MFA was not required during our initial Public Archives launch. We have since made it mandatory: every existing user is enrolled in MFA on their next sign-in, and new accounts cannot complete onboarding without it. We are working toward 100% coverage across the entire user base as accounts cycle through their next login.

SSO/SAML for enterprise customers is on our near-term roadmap and will give customer administrators centralized control over authentication.

Standard Works ships with no default or shared passwords. There are no built-in administrator credentials and nothing for a customer to "change after first login."

The only temporary credential we issue is a one-time password used during the signup flow. It expires after 7 days, and a user cannot finish onboarding without replacing it with a password of their own choosing combined with their required second factor.

Our stack is chosen so that whole categories of vulnerability are designed out by default rather than patched one bug at a time:

• Injection (SQL/NoSQL). All database access to our PostgreSQL (RDS) data runs through parameterized queries, never string-concatenated SQL, which eliminates classic SQL injection by construction. Queries to OpenSearch and AWS Neptune are likewise built from structured, parameterized inputs.
• Cross-site scripting (XSS). Our frontend is built on Next.js and React, which escape rendered output by default. We avoid raw HTML injection paths and rely on the framework's automatic escaping for user-controlled content.
• Memory-safety bugs. Our backend runs on FastAPI (Python) and our frontend on TypeScript/Node, both memory-managed runtimes that structurally avoid the buffer-overflow and use-after-free classes common to C/C++ code.

We treat this as ongoing work: as our codebase grows, we continue to favor frameworks and patterns that remove classes of bugs by default over those that require us to remember to avoid them.

Standard Works is a fully hosted SaaS product. Customers never install or run our software on their own infrastructure, so there is no patch for a customer to apply. Every customer always runs the latest, patched version of the product the moment we deploy it.

Our infrastructure runs on AWS, and we patch the platform centrally: application updates, dependency upgrades, and managed-service patches (RDS PostgreSQL, OpenSearch, Neptune) are applied by us, not by customers. This design removes the single largest source of unpatched, exploitable systems: out-of-date customer deployments.

We publish a Vulnerability Disclosure Policy that authorizes good-faith security research, defines a clear scope, and commits, through an explicit safe harbor, not to pursue legal action against researchers who follow it.

Reports go to security@standardworks.ai, and the policy is also discoverable at /.well-known/security.txt.

CVE records exist primarily for software that customers install and run themselves, where an unpatched flaw can persist on the customer's own systems. Because Standard Works is a hosted service that we patch centrally, CVEs are rarely applicable to our model. When we fix an issue, every customer receives the fix immediately and no vulnerable version remains in the field.

We are not a CVE Numbering Authority (CNA). Should a vulnerability ever warrant a CVE, for example in a component we distribute, we commit to issuing a complete and accurate record, including the appropriate CWE (weakness type) and affected-version information, through CISA and the MITRE CVE program.

Customers have access to audit logs covering actions taken on their data, including document views, searches, and other access events, so they can independently review who did what, and when, within their workspace.

Audit logging is on by default; a customer may choose to opt out. On the infrastructure side, we maintain server-side logging and monitoring across our AWS environment to detect and investigate anomalous activity.