Engineered for PHI — and built to recognized standards
For a healthcare interface engine, security isn't a feature — it's the foundation. MessageFoundry is built to a published Secure Development Standard and aligned with the frameworks a CISO already trusts: NIST SSDF, NIST 800-66 Rev. 2 (the HIPAA Security Rule), and OWASP ASVS 5.0 Level 3. It's secure by default, encrypted in transit and at rest, and clear about who's responsible for what. MessageFoundry is self-hosted and PHI-safe.
Mapped to the frameworks your auditors use
Four bodies of work answer four questions — how it's built, how it's tested, what controls it implements, and the application-security bar it's built to.
NIST SSDF — built securely
The secure software development lifecycle follows NIST SP 800-218 (SSDF) across all four practice groups — prepare, protect, produce, and respond — with threat modeling per interface, peer review, and secure-by-default design.
NIST 800-115 — tested in CI
Security testing follows NIST SP 800-115: automated SAST, software-composition analysis, and secret-scanning on every build, with dynamic testing per release. An independent external review and penetration test are planned after Early Access.
NIST 800-66 Rev. 2 — HIPAA-mapped
Implemented controls are mapped to the HIPAA Security Rule via NIST SP 800-66 Rev. 2 — access control, audit, integrity, and transmission security.
OWASP ASVS 5.0 Level 3 — self-assessed
Scoped chapter-by-chapter against OWASP ASVS 5.0 Level 3 — the highest assurance level, for applications that handle the most sensitive data — with every exclusion documented and justified. Across all 345 Level 3 requirements: 212 met, 0 failed, 0 partial, 133 not applicable.
Honest by design. NIST doesn't issue certificates for these frameworks, so we don't claim one — and the ASVS Level 3 result is our own self-assessment, not a third-party audit. In Early Access the software hasn't yet had an external code review or penetration test — which ASVS strongly recommends at Level 3 but does not require. These are alignment claims backed by evidence — the Standards document, that ASVS self-assessment, CI test reports, and an SBOM, published with our releases. "Built to," "self-assessed," "mapped to" — never "certified."
The safe configuration is the default one
You don't have to harden it — it ships hardened. TLS is on, encryption is on, accounts are least-privilege, and audit logging is verbose out of the box. Insecure options require an explicit, documented opt-in.
- TLS by default — network connections use TLS 1.2+ (prefer 1.3), including MLLP-over-TLS. When a connected system can't speak TLS, plaintext is supported within your secure network perimeter.
- Encryption at rest, on by default — message bodies encrypted with AES-256-GCM in the store (SQLCipher / database-native).
- Logic can't be injected through the data layer — Routers and Handlers are version-controlled code, never stored in the database. A data-layer breach (SQL injection, stolen DB credentials) reaches data that's already encrypted, RBAC-gated, and audited — but it can't change what the engine does.
- One audited door — the console and every other client reach the engine and its PHI only through the authenticated, RBAC-gated API; nothing holds a privileged in-process backdoor to the store.
- Deny-by-default RBAC — role-based, least-privilege access enforced on every action, with per-channel data-scope confinement.
- Tamper-resistant audit — a timestamped, user-attributed audit log; no PHI or secrets in logs, ever.
- Fail-closed — errors fail safe; faults never leak stack traces or sensitive data.
- Secrets stay out of code — sourced from an environment / secret store, enforced by pre-commit and CI secret scanning; the git history is kept clean.
Real auth for operators and connections — not a shared password
People sign in to the console and API; system connections carry their own credentials. Each uses the strongest mechanism available, recorded in the connection definition.
Operators (people)
- Local accounts — with built-in, required multi-factor authentication (MFA) — or Active Directory sign-in (LDAP), with opaque, revocable sessions and timeouts.
- Roles mapped to AD groups; deny-by-default, least-privilege RBAC on every action.
Connections (systems)
- Per-connection credentials — HTTP Basic over TLS or per-connection API keys — vaulted, scoped, rotated, and recorded.
- Mutual TLS (mTLS) client-certificate auth, OAuth 2.0 client-credentials, and SMART on FHIR (Backend Services), for connections that require them.
- group-Managed Service Account (gMSA) — optional. For Active Directory deployments, run the engine's Windows service under a gMSA so its password is AD-rotated and never stored in config, and use that identity for integrated database authentication. Not required — SQL authentication with a vaulted secret also works.
- TLS by default, including MLLP-over-TLS — with plaintext supported for endpoints that can't do TLS, inside your secure network perimeter.
- Per-connection IP allow-listing and network segmentation as defense-in-depth.
On the roadmap
- Passwordless Windows SSO — Kerberos / Integrated Windows Auth, so domain users sign in without a separate password.
- SSO federation via AD FS / Entra ID (OIDC / SAML) — so enterprise sign-in, and the MFA your organization's identity provider already enforces, flows through your existing IdP.
Across every mechanism: TLS by default, credentials and keys in a secret store (never in code or config), per-connection least privilege, and per-connection IP allow-listing / network segmentation as defense-in-depth.
Clear about who owns what
The software is built by one party and deployed by another. Stating the split plainly is itself a security control — neither side assumes the other has it covered.
MessageFoundry (the project)
- Secure development practices and secure-by-default configuration.
- Security testing and self-attestation of the software.
- Vulnerability response and coordinated disclosure.
- Documentation, evidence, and published self-attestations.
Your organization (the deployer)
- Your environment, host, and network security.
- Identity, credential, and key management in your environment.
- Backups, disaster recovery, and availability.
- Your HIPAA program — risk analysis, Business Associate Agreements, and the deployment's compliance.
Said plainly. The software supports a HIPAA-compliant deployment — it doesn't make you compliant on its own. Our self-attestation that the software was built securely is evidence for your assessment, not a substitute for it.
Safeguards, mapped to what the software does
Technical safeguards from the HIPAA Security Rule (via NIST SP 800-66 Rev. 2), and how MessageFoundry implements them.
| HIPAA safeguard | How MessageFoundry implements it |
|---|---|
| Access control — unique ID, authn, auto-logoff | Authenticated, role-based, least-privilege access with session controls and timeouts |
| Audit controls | Tamper-resistant, timestamped audit log; no sensitive data in logs |
| Integrity | Input validation; durable, ordered processing of messages |
| Transmission security | TLS by default for network transport (including MLLP-over-TLS) |
| Encryption (at rest & in transit) | Encryption at rest on by default, and TLS in transit |
| Administrative & physical | The deployer's environment and program — supported with evidence, not replaced |
Provenance you can verify
Open-source software is only as trustworthy as the pipeline that builds it. MessageFoundry ships as versioned, Sigstore-signed wheels with attested build provenance and an SBOM — integrity-verifiable releases that implement NIST SSDF and SLSA build-integrity controls, going beyond what OWASP ASVS L3 requires.
- Versioned & immutable — each release is a frozen
messagefoundry==X.Y.Zwheel; the build fails unless the built version matches the release tag — not a branch that can be force-pushed under you. - Signed & attested — every wheel ships with SLSA build provenance, Sigstore keyless signatures, and a CycloneDX SBOM (plus PEP 740 attestations on PyPI), binding the artifact to the exact source commit and CI builder — so adopters can verify it (e.g.
gh attestation verify) before installing. - Token-less publishing — releases are published to PyPI through OIDC-based Trusted Publishing, with no long-lived token to steal.
- Reproducible installs — pin a fully hash-locked dependency set and install with
--require-hashes. - CI security gates — SAST, software-composition analysis, and secret scanning run on every change; builds fail on new high / critical findings.
- Reviewed, protected code — branch protection, required peer review, signed commits, and no direct commits to main; a published
SECURITY.mdwith a private reporting channel feeds tracked, coordinated disclosure. - No real PHI in development — synthetic or de-identified data only, on disk-encrypted developer machines.
Don't take our word — review the evidence
We publish our Secure Development Standards and the evidence behind every claim, so your security team can review it directly. MessageFoundry is open source, so you can also read the code.
- Self-attested SSDF-aligned, security-tested per 800-115, self-assessed against ASVS 5.0 Level 3 (212 met · 0 failed · 0 partial · 133 N/A across 345 requirements), and controls mapped to the HIPAA Security Rule (800-66) — published with each release.
- Independent external code review and penetration test — planned after Early Access; Early Access has not yet been externally audited.
- A claims register records each published claim, its wording, and the evidence behind it.
- Not a NIST certificate — displayable certifications (SOC 2, ISO 27001, HITRUST) are a separate, organization-level track.
The assurance roadmap
An OWASP ASVS Level 3 self-assessment is a high bar to hold ourselves to — but it's still our assessment. The next steps are independent validation and the formal, organization-level certifications a mature vendor carries. Here's where each stands, plainly.
Independent validation
ASVS strongly recommends an external review at Level 3 — and we agree it's the right next step.
- External code review — a third-party security firm reviews the source against the same standard we self-assessed.
- Penetration test — an independent test of a real deployment, with the results summarized for adopters.
Both are planned after Early Access — today's release has not yet been externally audited. Sponsorship, not license fees, is what brings them forward.
Why not SOC 2 or HITRUST yet?
Because those certify an organization, not a piece of software. SOC 2 Type II and HITRUST attest that an operating company ran a defined set of controls over a period of time — they presume a staffed company, an audit window, and a recurring budget.
MessageFoundry is an open-source project in Early Access. We've put the software's security on the record now — secure-by-default controls, the ASVS L3 self-assessment, and signed, attested builds — and the company-level marks come as the project matures. SOC 2, HITRUST, and ISO 27001 sit on that organization-level track — funded, like the reviews, through sponsorship rather than license fees.
Frequently asked questions
Is MessageFoundry HIPAA compliant?
HIPAA compliance is a property of your whole deployment, not any single product. MessageFoundry is built to support it: PHI stays on your own infrastructure, every operator is authenticated, access to patient data is audited, traffic is encrypted with TLS and message bodies with AES-256-GCM, and controls map to the HIPAA Security Rule (NIST 800-66).
Is MessageFoundry PHI-safe — where does patient data live?
Yes. MessageFoundry is self-hosted, so PHI never leaves your infrastructure. There is no vendor cloud, no third-party processor, and no telemetry of message contents — you run the engine on your own servers, on-premises or in your own private cloud.
Is MessageFoundry self-hosted and on-premises?
Yes. MessageFoundry runs entirely on your own servers, on-premises or in your private cloud. It installs from PyPI, starts zero-config on SQLite, and scales to PostgreSQL or SQL Server. Nothing is sent to a vendor service.
How does MessageFoundry encrypt data?
TLS is enabled by default — network connections use TLS 1.2+ (TLS 1.3 preferred), including MLLP-over-TLS. Some older ancillary systems can't speak TLS; MessageFoundry also supports plaintext transport for those, which remains HIPAA-compliant inside your organization's secure network perimeter. At rest, message bodies are encrypted with AES-256-GCM.
Has MessageFoundry been independently security audited?
MessageFoundry publishes a self-assessment against OWASP ASVS 5.0 Level 3 (212 met, 0 failed, 0 partial, 133 N/A of 345) plus its Secure Development Standards. It has not yet had an independent external code review or penetration test — both are planned after Early Access.
Evaluating MessageFoundry for PHI?
Start with the Standards, the code, and the evidence — then bring us your security team's questions.