A lot of cloud providers describe their compliance posture with a wall of logos and a footer line that says “SOC 2 Type II certified.” The certificate is real, the program behind it is real, and the implementation behind the program is almost never something the buyer ever sees.
That gap is the reason this post exists. Mid-market enterprises buying managed cloud do not want a logo wall. They want to see the posture: how identity is handled, how audit logs are protected, what cryptographic guarantees are in force, what stays the customer’s responsibility. Acquirers running diligence on a cloud platform want the same answers in a more structured format.
This is the operating picture of compliance at Open Edge Cloud, written the way an enterprise diligence team would read it. The target baseline is FedRAMP Moderate (NIST SP 800-53 Rev 5). The platform is built to a “mostly there” posture against that baseline, with an OSCAL-based artifact program in version control. We follow SOC 2 and ISO 27001 control frameworks. We are not certified or audited under any of these programs and we will not pretend otherwise.
1. Cryptography
Every cryptographic operation on the platform runs against a FIPS 140-3 validated OpenSSL provider on Ubuntu 24.04 LTS. The validation is real: CMVP Certificate #5115, searchable on the NIST validation list. TLS handshakes at the edge, encrypted volumes, Barbican-managed secrets, Keystone tokens, backup archives, and inter-site replication streams all share the same validated provider.
Specific posture choices worth naming:
- Password hashing: Keystone hashes user passwords with PBKDF2-SHA512. PBKDF2 with SHA-2 is FIPS-approved under SP 800-132. bcrypt, the legacy default, is built on the Blowfish cipher and is not FIPS-approved. bcrypt was retired across the cluster earlier this year, with a monitoring rule that flags any regression.
- TLS: HAProxy front-ends terminate on TLS 1.3 only, AEAD ciphers only (AES-GCM and ChaCha20-Poly1305). Older protocol versions are not negotiable on any public listener.
- Customer-managed keys for volume encryption: An AES-256 XTS encrypted volume type is available on the platform with per-volume keys minted by Barbican at create time. Customers retain key custody.
- At-rest encryption: Block storage in the production cluster is encrypted at the device layer with AES-XTS and full-length keys. Backups are GPG-AES-256 encrypted at the source host before they leave the machine; the encryption keys are not stored on the source host.
- Customer-managed key generation: Barbican supports six secret types including RSA up to 4096-bit and elliptic curve through P-521. We patched the upstream Barbican EC validator to make P-521 generation work end-to-end and submitted the fix upstream.
2. Identity, authentication, and access
There is no shared username and password floating around the platform. There never has been. The identity stack is built so that the only thing the user owns is their identity in their own identity provider.
- Federated SSO: Keycloak fronts the dashboard and the OpenStack API surface. OIDC Authorization Code with PKCE is the supported path. SAML 2.0 federation is wired up for Active Directory, Okta, Entra ID, Auth0, or any conforming IdP. LDAP and AD direct integration is supported for organizations not yet on a modern IdP.
- MFA: TOTP and WebAuthn hardware keys, enforced at the IdP. Hardware-key WebAuthn meets every reading of NIST SP 800-63B AAL2 and AAL3.
- No resource owner password credentials flow: there is no path for a script to trade a username and password for a token. ROPC is the path that gets you breached and we did not implement it.
- Programmatic access: CI/CD pipelines and infrastructure-as-code use application credentials, not user passwords. Application credentials are scoped to a single project and revoke atomically without touching the human user.
- Scoped RBAC across the OpenStack API surface: oslo.policy runs with new-defaults and scope enforcement enabled across every API service. The three-tier admin/member/reader policy is enforced at the service layer, not just at the dashboard layer.
- Dashboard RBAC: separate built-in roles for organization administrators, project administrators, members, read-only users, security personnel, and auditors. The auditor role is read-only at domain scope with access to the audit log surface.
3. Audit and accountability
Every API call against OpenStack is logged with requester identity, project, timestamp, parameters, and outcome. The relevant audit streams (identity, secrets, volumes, networks, compute, images, orchestration, DNS, load balancers, plus system journals from every host) all feed a hardened log pipeline.
The pipeline ships logs to two destinations:
- Real-time analysis for operations, alerting, and customer-visible audit reporting.
- Long-term archive in immutable encrypted object storage, on a multi-year retention horizon that exceeds the FedRAMP Moderate baseline. Archive objects are encrypted at the source host before they leave the machine; the encryption keys are not on the source host.
A heartbeat metric watches the archive pipeline. If the archive is silent for longer than expected, an on-call engineer is paged.
Audit data access is restricted to operators with the auditor or security role and is itself audited. Customer audit access is read-only through the dashboard, exportable, and pre-mapped to SOC 2 and ISO 27001 control families. The same surface extends to CMMC and FedRAMP control mappings on request.
4. System and information integrity
Wazuh runs on every cluster host. The agents do four things:
- File integrity monitoring on the directories that hold configuration, secrets, SSH state, TLS material, and audit configuration. Real-time plus whodata. Any change outside a known deployment window pages a human.
- Rootkit and IOC detection with the upstream Wazuh ruleset and a curated IOC pattern set.
- Security Configuration Assessment against the CIS Ubuntu 24.04 baseline on a weekly cadence, which exceeds the FedRAMP Moderate monthly OS-scan baseline. Results aggregate to a monthly POA&M roll-up.
- Active response on a curated set of triggers (brute-force SSH attempts trigger an IP block, for example).
Wazuh alerts ship to the same encrypted long-term archive as the OpenStack audit log, on the same multi-year retention horizon.
5. Host hardening
Every cluster host is hardened against a tailored Canonical USG CIS Level 2 profile. The tailoring profile carries a set of named accept buckets that each cover a specific class of CIS rule where the literal CIS expectation conflicts with how a managed cloud hypervisor actually runs (single-tenant network model with OVN owning the boundary, host-side firewall responsibilities pushed up the stack, FIPS cipher preservation, and so on). Every accepted rule has a documented compensating control and a NIST family mapping in our control accept catalog.
After applying the tailored hardening, the cluster lands in the high nineties on effective CIS L2 pass rate. Independent cross-checks (OpenSCAP STIG and Wazuh SCA against CIS L1) move in step. The hardening process and the accepts catalog are part of the OSCAL artifact program below.
6. Configuration management
The cluster is deployed with Kolla-Ansible. The inventory, globals, group variables, and service templates are the baseline configuration in version control. There is no out-of-band drift surface.
Two posture choices that make a difference at audit time:
- The deployment tree is signed. Every commit to the production deployment branch carries a GPG signature from a known operator key.
- The control-plane configuration mirror is pull-only. Cluster hosts cannot mutate the configuration that produced them. The signing key never leaves the operator workstation. This is one of the most underappreciated controls in operational cloud and we treat it as load-bearing.
Reconfigures are operated as cost-incurring operations, observed one service at a time. Broker-side policies are preferred to immutable-argument changes when both options are available.
7. Boundary protection and network architecture
- Per-tenant isolated networks with DHCP, DNS, and IPv4/IPv6 dual stack. Tenants cannot see each other’s traffic.
- Security groups on every port with default-deny, stateful firewalling, and an effective-rules view that merges policy across groups so the operator can see what is actually applied.
- Visual traffic simulator that lets a customer test a firewall rule change against synthetic flows before applying it. This is a unique feature in the OpenStack ecosystem and it changes the failure mode of firewall changes from “deploy then find out” to “model then deploy.”
- Shadowed rule detection flags ineffective rules that are masked by broader rules.
- Permissive rule warnings flag any-source rules at create time.
- DNSSEC is signed end-to-end on managed DNS zones.
8. Data residency and sovereignty
Every byte of customer data lives in a US datacenter. The current active site is Iron Mountain VA-1 in Manassas, Virginia. A second site at STACK POR02A in Hillsboro, Oregon is coming online in Q2 2026.
Every operator with production access is a US person. Every contracted engineer is a US person. Every subprocessor that handles customer telemetry is a US entity operating on US infrastructure.
9. Backup and continuity
- Encrypted, scheduled backups for identity state, key material, and database state. Every backup is GPG-AES-256 encrypted at the source host. A heartbeat alert fires if a daily backup window is missed.
- Application-consistent snapshot scheduling is operational for customer workloads on Cinder-backed volumes, with QEMU guest agent quiescing for filesystem and database-level consistency.
- Tested recovery: end-to-end recovery from the encrypted archive runs on a documented cadence.
10. The OSCAL artifact program
The compliance posture above is not narrated only in this blog post. It is materialized in NIST OSCAL format in a dedicated repository, authored and validated with Compliance Trestle.
- Catalog: NIST SP 800-53 Rev 5
- Profile: FedRAMP Moderate baseline (imported from GSA’s FedRAMP automation repository)
- Component definitions: per-component control implementation evidence for the identity, secrets, storage, database, and observability stack
- System Security Plan, Security Assessment Plan, Security Assessment Reports: in active drafting
- Plan of Action and Milestones: tracked gaps with remediation timelines
- Tiered gap reports: a control-family framework with per-tier coverage and evidence pointers
CI runs OSCAL validation on every change. The diligence team for an acquirer or a large prospect can read the artifacts directly under NDA.
What we are not
Honest compliance posture includes naming what we do not have.
- We do not hold a FedRAMP Moderate authorization. We are building the engineered platform that is mostly there against the FedRAMP Moderate baseline. The authorization itself is the acquirer’s path forward.
- We are not SOC 2 certified. We follow the SOC 2 control framework.
- We are not ISO 27001 certified.
- We do not sign Business Associate Agreements. The platform architecture supports HIPAA-eligible workloads; customers with PHI requirements should expect a scoping conversation before signing.
- The operational halves of incident response, contingency planning, and continuous monitoring (24×7 SOC, on-call rotation, incident command, monthly POA&M submission, agency reporting) are out of platform scope under our scope-reduction model. They are the acquirer’s responsibility.
What this means for a buyer
If you are evaluating Open Edge Cloud for a workload with a real compliance footprint, the conversation we want to have is the one where you bring your control mapping and we walk through the platform answer for each control with you. We will not sell you a logo. We will not sell you a checkbox. We will show you the posture, the policy, and the failure mode.
If you are an acquirer doing diligence on the platform, the artifacts are real and they are version-controlled. We can walk the SSP, the gap reports, the POA&M, and the assessment results under NDA on a defined timeline.
That is the operating picture. The platform is the artifact. The diligence is the conversation.
Reach out at https://open-edge.io/contact and tell us what framework you are mapping to. We will bring the receipts.