Security Architecture

Security that's
structural, not
a policy document.

Zero-touch credential architecture means we cannot read your API keys —€” not that we promise not to. AES-256-GCM encryption, OWASP pen-tested, SSH MFA enforced, CSP hardened. Here's exactly how it works.

Six Security Pillars

Every layer of the
platform is hardened.

🔑
Zero-Touch Credentials

Integration API keys and tokens are encrypted with AES-256-GCM before they're stored. The encryption key is derived per-tenant. We structurally cannot decrypt your credentials —€” it's not a policy, it's architecture.

🔒
Encryption at Rest

All storage volumes are encrypted with LUKS AES-256 at the disk layer. All sensitive credentials within the application are additionally encrypted with AES-256-GCM at the application layer. Two independent encryption layers.

🌐
TLS 1.2+ Everywhere

All traffic —€” admin, portal, API, tenant subdomains —€” is served over TLS 1.2 minimum. HTTP is not available. HSTS enforced. Certificate renewal is automated and monitored.

🧺
Multi-Factor Authentication

TOTP-based MFA is required for all admin portal access and all SSH access to infrastructure servers. There is no bypass path. Secrets are stored in server-side environment files, never in application config.

🛡️
Content Security Policy

All Quad Digital web properties are deployed with a strict Content Security Policy —€” no unsafe-inline for scripts or styles, no data: URIs, frame-ancestors restricted. Enforced at the web server layer, not the application.

🧱
Tenant Isolation

Each institution operates in a fully isolated PostgreSQL database. Credentials, configurations, user records, and audit logs are completely separated. There is no shared schema between tenants. Cross-tenant access is structurally impossible.

How It Works

The zero-touch
credential flow.

When a tenant administrator configures an integration —€” Canvas, Banner, Microsoft 365, anything —€” the credential never touches our application in plaintext after the initial submission. Here's the exact flow from entry to storage to use.

The result: your integration credentials are available to the platform to make API calls on your behalf, but are structurally inaccessible to Quad Digital staff, support engineers, or anyone else who might query the database.

01
Admin enters credentials
Tenant administrator enters API key or token in the integration wizard. Transmitted over TLS 1.2+. Never logged.
02
Encrypted at API layer
The backend API encrypts the credential using AES-256-GCM with a per-tenant key before it touches the database. Plaintext never written to disk.
03
Stored in encrypted vault
The encrypted blob is written to the tenant's isolated PostgreSQL record. The database row contains ciphertext only —€” unreadable without the encryption key.
04
Decrypted only at runtime
When the platform makes an API call on tenant's behalf, the credential is decrypted in memory, used for the request, and immediately discarded. Never cached. Never logged.
05
Admin re-enters to update
To change a credential, the admin enters the new value through the same wizard. The old ciphertext is overwritten. There is no way to retrieve or display the stored value.
06
We cannot read it
Quad Digital support staff, engineers, and database administrators can access the encrypted vault — and see ciphertext only. The encryption key is not accessible outside the API runtime. This is not a policy statement. It is an architectural constraint.
Technical Specifications

The full security stack.

Authentication & Access
Admin MFATOTP (Google Authenticator)
SSH AccessKey + TOTP required
Session TokensJWT, 8-hour expiration
SSOSAML 2.0 / Shibboleth / OIDC
Password Hashingbcrypt (cost factor 12)
Access ControlRole-gated at API layer
Network & Transport
TLS Version1.2 minimum enforced
HTTPDisabled —€” redirects to HTTPS
HSTS•Enforced with preload
CSPStrict —€” no unsafe-inline
Security HeadersX-Frame-Options, X-Content-Type, Referrer-Policy
WAFModSecurity with custom ruleset
Data & Storage
Disk EncryptionLUKS AES-256
Credential EncryptionAES-256-GCM (per-tenant key)
Tenant IsolationSeparate PostgreSQL database per tenant
Data ResidencyUnited States only
Backup Retention7 days
Audit Log Retention90 days
Secrets Management
App SecretsServer-side env file (chmod 600)
JWT SecretStored in /etc/quadhub-secrets.env
DB CredentialsNever in application config files
Git RepositoriesSelf-hosted Gitea (on-prem only)
.env FilesNever committed to version control
Future StateHashiCorp Vault (post-revenue)
Penetration Testing

Independent pen testing.
Zero critical. Zero high.

We conduct web application penetration testing against the QuadHub platform from a dedicated testing instance on our infrastructure. The most recent full scan returned zero Critical and zero High severity findings. Medium and Low findings are tracked and remediated on a defined schedule.

Penetration testing is conducted against the full platform stack —€” web application, API endpoints, authentication flows, and admin interface —€” not a subset.

0
Critical
0
High
Pass
Medium
Pass
Low
Test Configuration
MethodologyOWASP Top 10 + custom rulesets
ScopeFull platform —€” web, API, auth
FrequencyAfter major releases
InfrastructureInternal test instance
Security Questions

Want to go deeper
on the architecture?

We're happy to walk through the security architecture in detail with your IT security team or compliance officer. No slides required —€” just a technical conversation.