Security controls, stated precisely

1. Authentication and sessions

2. Authorization

• AtlasOA: three roles (administrator, editor, viewer) with six adjustable permissions: read, modify, delete, import, export, and administer. Today some administration screens and attachment actions check that a user is signed in rather than the specific permission, so give accounts only to staff you trust with those screens until this is corrected. There is no per-program scoping: a user who can read sees all programs. Optional modules are enabled per license.
• Atlas K-12: four roles (teacher, counselor, building administrator, district administrator) plus an MTSS Coordinator designation. Roles are read from the database on every request, so a change takes effect immediately; an automated regression test checks that no page trusts a role stored in the session. District administrators see all schools; everyone else sees only their assigned school, and a user with no school sees nothing. Restricted support notes are limited to counselors and administrators. Administrators cannot grant a role above their own.

3. Audit logging

• Both products keep a tamper-evident audit log: each entry includes a SHA-256 hash of its contents and the previous entry, so an edited or deleted entry breaks the chain. Atlas K-12 can verify the full chain on demand from its Security Health page; AtlasOA checks the most recent 100 entries each time the Audit Log page opens.
• AtlasOA records sign-ins, failures, lockouts, password and user changes, imports, data changes with old and new values, backups, settings, license changes, alerts, and integration connection tests. It can be searched, filtered, and exported to CSV.
• Atlas K-12 records sign-ins, single sign-on decisions, user and data changes, imports, interventions, notes, SEL activity, and read events such as student profile views, report card downloads, and roster exports. A Security Health page shows 24-hour activity, anomaly flags, chain status, and recent single sign-on events.
• Tamper-evident is not tamper-proof: someone with write access to the server's files could rewrite the whole chain. Protect the server and keep backups.

4. Web application protections

• CSRF: a per-session random token is required on every state-changing request and compared in constant time.
• SQL injection: queries use parameter placeholders. Table and column names that must be inserted into SQL are checked against allowlists.
• Cross-site scripting: template output is escaped by default.
• Security headers: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy on every response (AtlasOA also sends X-XSS-Protection and Permissions-Policy); HSTS when HTTPS mode is turned on (AtlasOA: the FORCE_HTTPS setting; Atlas K-12: reverse-proxy mode). AtlasOA uses per-request script nonces and allows the application's own inline event handlers by hash; Atlas K-12 still allows inline scripts in its policy.
• Debug mode is off in shipped builds.

5. File uploads

• Request size limits: 16 MB (AtlasOA) and 32 MB (Atlas K-12).
• File names are sanitized and file types are restricted by extension to documents, spreadsheets, and images (plus MP4 for Atlas K-12 strategy resources).
• Atlas K-12 downloads check that the user may view that student and confirm the file stays inside the upload folder. AtlasOA downloads require sign-in and confirm the file stays inside the upload folder.
• AtlasOA validates CSV imports in memory with size, row, and column limits. Atlas K-12 CSV imports are bounded by its 32 MB request limit.
• File contents are not inspected beyond the extension, and there is no antivirus integration; use your endpoint protection on the server.

6. Encryption

• In transit: the applications serve HTTP and rely on your reverse proxy (for example IIS) for HTTPS. Outbound connections to SIS, LMS, and email servers are encrypted when the address you configure supports it. Certificate validation is on by default for the AtlasOA LMS connectors and the Atlas K-12 SIS connectors. It is off by default for the AtlasOA Jenzabar SQL connection (you can turn it on), and Atlas K-12 email alerts do not yet validate the mail server's certificate.
• Stored credentials: stored passwords and client secrets for SIS, LMS, email, and backup destinations are encrypted with Fernet (AES-128 with HMAC-SHA256), using a key derived from the installation's secret key with PBKDF2-HMAC-SHA256 at 200,000 iterations. Atlas K-12 keeps them in its database and can instead use a self-hosted Infisical vault; AtlasOA keeps them in a local settings file. In AtlasOA, Canvas and Moodle API tokens are not yet encrypted; restrict access to the data folder.
• At rest: the database, uploads, and backups are not encrypted by the application. Encrypt the disk (for example BitLocker). This is listed on Shared responsibility.

7. Network isolation

• Neither product has telemetry, crash reporting, a license server, or an update server.
• Atlas K-12 blocks outbound connections from its main application in software and logs each attempt. Research-site and SIS connections are made only by a separate fetcher process restricted to an allowlist and the SIS hosts you configure. When Microsoft Entra single sign-on is enabled, the main application may also reach Microsoft's sign-in service. Two optional tools run outside this guard: the building health check (a scheduled task you enable) and command-line material-pull tools used during setup. This software guard is a second line of defense; your firewall remains the first.
• Every possible connection is listed on Network requirements.

8. How we build and test

• Automated tests: Atlas K-12 has about 400 automated tests, including 25 security-focused test files (authorization scoping, cross-record access, CSRF on sign-out, single sign-on token validation, audit-chain integrity, network isolation, credential handling). AtlasOA has several hundred automated checks across its feature, trial-activation, diagnostics, and integration-simulation suites. Test results for recent AtlasOA releases are summarized in the changelog.
• Security review before release: recent releases were reviewed before shipping by reviewers separate from the builder, with attention to the OWASP Top 10; findings were re-checked by separate verifiers and fixed before release. Atlas K-12 completed a platform-wide review in June 2026 with 43 findings, all closed. These reviews are internal; they are not an independent third-party assessment. See Independent validation.
• AI-assisted security testing: our development organization is enrolled in Anthropic's Cyber Verification Program, which lets our team use Claude (including the Fable model) for deeper security testing of both products on isolated test systems with synthetic data. Testing is under way; results will be summarized on Independent validation. This is internal testing, not a third-party assessment.
• Release control: releases are versioned installers with public release notes. AtlasOA evaluation installers are delivered with their SHA-256 hash so you can verify the file.
• Vulnerability handling: see Vulnerability reporting.
• Not in place today: automated dependency scanning, static analysis in a build pipeline, and pinned dependency versions for source installs.

9. Not implemented yet

Listed here so no one has to discover them during an evaluation:

• Multi-factor authentication for local accounts (both products); single sign-on for AtlasOA.
• Self-service or administrator password reset in Atlas K-12 (today a forgotten password needs a database change or a new account), and password complexity rules beyond the 8-character minimum (both).
• Per-program data scoping in AtlasOA; roster-level (rather than school-level) scoping for Atlas K-12 teachers.
• Encryption of the database by the application itself (use disk encryption).
• Code-signed installers. Current installers are not code-signed, so Windows may show a publisher warning; verify the file hash we provide with the installer.
• Immediate sign-out of deactivated users (Atlas K-12 blocks their next sign-in; an open session can last up to 8 hours).

The full list is on Known limitations.