Secure by Design Pledge progress report.

Every administrator account supports time-based one-time password (TOTP) multi-factor authentication from any standard authenticator app, so districts are not locked into one vendor. Enrollment secrets and recovery codes are protected at rest and are never redisplayed after setup.

District administrators can require MFA across their entire organization, so enrollment is not left to individual discretion. This is the control CISA points to as the strongest version of this goal: enforcement at the organization level rather than a per-user suggestion.

We also support standards-based single sign-on in the baseline product at no additional cost, through Google Workspace, Microsoft 365 and Entra ID, ClassLink, and SAML 2.0 for identity providers including Okta, OneLogin, ADFS, Ping, and Shibboleth. Districts that already enforce phishing-resistant MFA at their identity provider inherit that posture in Manage1to1 without buying an upgraded tier.

Manage1to1 ships no default passwords. There is no universally shared credential present across installations, which is the specific pattern CISA defines as a default password, and there is no documented break-glass account for support staff to use.

Administrator credentials are created per district during provisioning, and only the district ends up holding them. Passwords are never stored in a form we can reverse, so we cannot read, recover, or disclose one. Districts can enforce their own password policy rather than inheriting ours, and password resets use short-lived, single-use links.

Programmatic access follows the same rule. API keys are displayed to the administrator exactly once and are not recoverable afterward, including by us. A credential we cannot retrieve is a credential we cannot leak.

The class we have committed to eliminating structurally is SQL injection.

Database access runs through a centralized data-access layer that parameterizes values by default. The design goal is structural rather than procedural: developers do not have to remember to escape input, because the safe path is the default path and constructing an unsafe query requires deliberate effort that stands out in review. Request input never reaches a query as anything other than a bound parameter.

We apply the same approach to cross-site scripting, where untrusted markup is sanitized against an allowlist and template output is escaped at render time by default. Our application also runs on a memory-safe runtime, so the memory-safety vulnerability classes CISA highlights do not apply to our application code.

This goal is marked ongoing rather than finished on purpose. Eliminating a vulnerability class is a property you maintain, not a milestone you pass.

Manage1to1 is delivered exclusively as SaaS over HTTPS. We apply security patches ourselves, centrally, and districts take no action to receive them. CISA names this outcome directly in its example approaches for this goal: for cloud and SaaS products, apply patches so the burden is not on the customer.

There is no unsupported version running in the field, because there is no version for a district to run. We use calendar versioning and every customer is on the current release at all times. Updates are included at every pricing tier with no maintenance contract and no long-term-support upsell, and release notes are published publicly.

Automated vulnerability scanning runs continuously against the platform and its infrastructure, which is how patch-worthy issues reach us in the first place.

Our Responsible Disclosure Policy authorizes good-faith security testing by members of the public, commits us to not pursuing or recommending legal action against researchers who follow it, provides a dedicated reporting channel, and allows for coordinated public disclosure.

The policy is also published in machine-readable form as a security.txt file so researchers can find it without hunting through our site, which is the discoverability step CISA calls out under this goal.

We commit to issuing CVEs in a timely manner for any critical or high-impact vulnerability in Manage1to1 that either requires action by a district to remediate or shows evidence of active exploitation, with accurate CWE and CPE fields in every record.

We want to be precise about what that means for a SaaS product rather than overstate it. Because districts run no Manage1to1 software of their own, the ordinary remediation path is that we patch centrally and no customer action is required, so the customer-action trigger above is rarely met. That is a property of the delivery model, not evidence of a clean record, and it is why we pair this commitment with direct written notification to affected districts and with the 72-hour breach notification commitment in our Data Security and Privacy Plan.

Audit logging is part of the baseline product at every pricing tier, not a premium add-on and not a separate observability SKU. Administrators can review activity across configuration changes, administrator sign-ins including federated SSO logins, user and device record changes, and access to business-relevant data such as tickets, assets, and invoices.

Logs are retained for the life of the district's contract at no additional charge. CISA's example for cloud and SaaS providers is a set retention window such as six months; we do not expire audit history on a rolling window, so a district investigating an incident is not racing a retention clock.

On termination, district data including audit history is available for full export to CSV for 30 days before secure deletion.