Iron Bank Explained: What It Covers and What It Doesn't

Ori Sela

Oct 22, 2026 | 8 Minutes

Iron Bank, explained

Iron Bank is a public catalog of hardened containers maintained by the US Department of Defense's Platform One program. Its images are hardened to DoD standards and widely used as a starting point by teams pursuing FedRAMP High authorization. What it is not is an approval mechanism: pulling from it does not make your system compliant, and it does not remove your obligation to validate, scan, and document every image inside your authorization boundary.

Key takeaways

It is a hardened image catalog, not an approval. FedRAMP pre-certifies no container images; the obligation to validate and document stays with you.
Three requirements apply regardless of source: FIPS 140-3 validated cryptography, STIG or GPOS SRG hardening, and continuous scanning with POA&M reporting.
Hardening decays with every upstream update. Re-verification is the recurring cost, estimated at two weeks to three months per engineer per environment.
Evidence has to be machine-readable. SCAP reports and runtime FIPS verification, not datasheet claims.
Judge sources on remediation cadence, not today's CVE count. A contractual SLA is what survives continuous monitoring.

What the Platform One catalog actually is

It is a repository. Platform One maintains it, the images in it are hardened against DoD configuration standards, and it is public - anyone can look at what is in there and how it was built.

That makes it genuinely useful as a reference. If you want to see what a DoD-grade hardening baseline looks like applied to a real workload, the catalog is an unusually transparent example. Teams building toward FedRAMP High often use it to calibrate what "hardened" should mean before committing to an approach.

Does using it make you FedRAMP compliant?

No - and this is the most common misreading. FedRAMP does not pre-certify or pre-approve container images. There is no list you can pull from that confers compliance. What FedRAMP defines is a set of security controls, drawn from NIST Special Publication 800-53, that every component inside your authorization boundary has to satisfy - regardless of where that component came from (which container images are pre-approved for FedRAMP workloads).

The practical consequence: an image being widely used, officially maintained, or published by a major programme does not make it compliant by default. The burden to validate, document, and continuously monitor stays with you as the cloud service provider.

The three requirements the catalog does not discharge for you

Whatever your source, three requirements apply to virtually every image in a FedRAMP boundary:

FIPS 140-3 validated cryptography. All encryption inside the boundary must use a module validated under NIST's Cryptographic Module Validation Program - such as the OpenSSL FIPS Provider, BoringCrypto, or Bouncy Castle - configured in accordance with the security policy on its CMVP certificate. Using the same library outside its validated configuration does not count.
STIG hardening. FedRAMP System Security Plan requirements point to DISA Security Technical Implementation Guides for configuration settings. Where no container-specific STIG exists, the General Purpose Operating System SRG applies; CIS Benchmarks at Level 1 or 2 are accepted where neither is available.
Continuous vulnerability management and POA&M reporting. Images must be scanned at least every 30 days, with findings documented in the Plan of Action and Milestones. Critical and high CVEs carry a 30-day remediation requirement under standard FedRAMP rules.

Each of these is an ongoing obligation, not a one-time check. We go deeper on the hardening half in STIG compliance for containers.

Why "hardened once" is the wrong mental model

Hardening decays. Every upstream update changes the package set, which means the hardening has to be re-verified and re-documented. Manually applying and verifying STIG controls across a catalog of images typically takes two weeks to three months per engineer for a single environment, and that cost recurs.

The same applies to the CVE baseline. An image that starts clean but is not actively maintained accumulates findings. What matters for an authorization that has to survive continuous monitoring is not today's CVE count - it is the remediation cadence behind it, and whether that cadence is backed by anything enforceable.

Comparing your options

Dimension	Platform One catalog	Public upstream images	Minimal / distroless	Purpose-built vendor images
Hardening baseline	DoD standards, applied	Undefined	Minimal footprint, no STIG baseline	Pre-hardened to DISA STIG
FIPS-validated crypto	Varies by image	Generally absent	Not implied by minimalism	CMVP-validated module per image
Who re-verifies on update	You	You	You	Vendor
CVE remediation commitment	None contractual	None	None	Contractual SLA
POA&M evidence	You assemble it	You assemble it	You assemble it	Generated and forwarded
Cost model	Free, high internal effort	Free, highest internal effort	Free, high internal effort	Paid, low internal effort

The cost in the "internal effort" columns is not hypothetical. Industry estimates put DIY FIPS validation at $5,000–$10,000 per image, STIG hardening at $2,000–$5,000 per image, and continuous CVE management at $115,000–$230,000 annually, with monthly POA&M reporting adding $5,000–$10,000 per image - roughly $127,000–$255,000 per image per year in total (which container images are pre-approved for FedRAMP workloads).

How to evaluate any hardened image source

Five checks, in order of how often they get skipped:

Runtime FIPS verification, not documentation. Assessors expect evidence that the validated module actually handles cryptographic operations - produced by executing approved and unapproved algorithms and reporting observed behaviour, not a claim in a datasheet.
Machine-readable STIG evidence. SCAP-compatible scan reports an assessor can validate. A compliance claim without machine-readable output does not satisfy the requirement in practice.
Remediation cadence, backed by contract. Ask what the committed timeline is and whether it is written down. Echo's published SLA commits to 7 business days for critical and high CVEs and 10 for medium and low (Echo Images and Libraries SLA, last updated 10 May 2026) - comfortably inside FedRAMP's 30-day window.
SBOM availability in both formats. SPDX and CycloneDX, per tag, so assessors and agency reviewers can track component-level exposure.
Scanner compatibility. Images that your existing scanners do not fully recognise create blind spots in your vulnerability data - which becomes an audit finding. Echo images are recognised by the major scanners including Wiz, Orca and Trivy, with no proprietary tooling required.

Where Echo fits

Echo's position is not "instead of a reference catalog" - it is that the catalog solves the hardening snapshot, and the authorization is a continuous-monitoring problem. Echo images use a CMVP-validated cryptographic module (OpenSSL, BoringCrypto, Bouncy Castle) configured per its official security policy and the GPOS STIG, arrive pre-hardened against DISA STIG requirements, and ship with a STIG validation tool and a FIPS runtime tester that generate per-image evidence automatically. POA&M-ready reports covering all unfixed vulnerabilities are updated and forwarded to auditors in real time, and all artifacts - images, SBOMs, provenance - are signed and attested using cosign and sigstore.

FAQ

Is the Platform One catalog free to use?

It is a public catalog maintained by the Department of Defense's Platform One programme, so the images themselves are openly available. The cost is not the artifact - it is the work that remains yours: validating FIPS configuration, producing machine-readable STIG evidence, scanning on a 30-day cadence, maintaining POA&M documentation, and re-verifying hardening every time an upstream component changes.

Can I use its images directly in a FedRAMP High system?

You can use them as a starting point, which many teams do. But they carry no FedRAMP approval, and every image inside your authorization boundary still has to meet NIST SP 800-53 controls and be documented in your authorization package. Treat the catalog as a hardening reference, not as a compliance shortcut, and plan for the continuous-monitoring work regardless.

What is the difference between STIG hardening and FIPS validation?

They address different things. STIG hardening is configuration: locking down settings, removing unnecessary components, and meeting DISA baselines. FIPS validation is cryptographic: using a CMVP-certified module in its validated configuration for all encryption inside the boundary. An image can be thoroughly STIG-hardened and still fail FIPS requirements, and the reverse is equally possible.

How do I prove hardening to an assessor?

With machine-readable output rather than assertions. For STIG, that means SCAP-compatible scan reports covering each required check. For FIPS, it means runtime verification - executing approved and unapproved cryptographic algorithms and reporting what the module actually did. Documentation-only claims are the most common reason hardening evidence gets rejected during assessment.