Sensitive evidence lives in the approved Wickr and retention boundary. Athena’s SaaS manages sanitized workflow, status, control mapping, and approved conclusions.
Athena's SaaS is not FedRAMP authorized. When Regulated Data Boundary controls are enabled, AWS Wickr Premium serves as the FedRAMP Moderate-authorized collaboration component for sensitive communications and evidence exchange. Athena’s SaaS remains outside the regulated-data boundary and receives only sanitized, non-CUI, non-ITAR, or customer-approved information.
Regulated communications and evidence remain within the approved AWS Wickr and customer-controlled retention environment. Athena Fortify-CMMC stores only approved metadata, opaque references, workflow status, responsibilities, and sanitized conclusions.
No. Athena does not represent Fortify-CMMC as FedRAMP authorized. Athena has intentionally architected CUI and regulated evidence out of its SaaS. For regulated engagements, AWS Wickr is used as the authorized secure-collaboration component only after the applicable offering, region, authorization scope, configuration, and supporting AWS services have been validated. CUI and regulated evidence remain within the approved Wickr and customer-controlled retention environment. Athena manages the CMMC workflow through approved metadata, external references, responsibilities, status, and sanitized conclusions.
This design gives the customer a clear, defensible system boundary: regulated content stays in the approved environment, while Athena manages the work required to prepare for and sustain CMMC assessment readiness.
Athena’s advantage is not a claim that its SaaS is FedRAMP authorized. Athena’s advantage is a deliberately controlled architecture that keeps CUI out of its SaaS while coordinating regulated collaboration through a separately validated AWS Wickr environment. This reduces unnecessary compliance exposure while giving customers a governed, traceable CMMC readiness and evidence-management process.
Regulated content, retention, and analysis are separate layers with separate authorizations. Nothing is inherited.
AWS Wickr Premium is the FedRAMP Moderate-authorized collaboration component when deployed using the applicable authorized offering in the validated AWS region recorded for this engagement, after the offering, region, authorization scope, configuration, and supporting AWS services have been validated. End-to-end encrypted messaging, calling, file transfer, and rooms carry the regulated conversation and the CUI itself.
The controlled retention repository is a separately configured customer component. It is not represented as FedRAMP authorized merely because AWS Wickr is authorized; its authorization boundary must be determined and documented by the customer. Retention is customer-controlled, keyed with customer-managed keys, and evidenced per service — never inherited.
Athena runs the assessment: objectives, control mapping, findings, POA&Ms, SPRS, and the assessor package. It receives artifact identifiers, sanitized status, and approved conclusions — never regulated content.
Message bodies, files, and retained-record content are permanently unsupported capabilities. Content reads are refused before any network call and the refusal is audited.
Vault material is wrapped per user; customers may supply their own key material so the analysis layer never holds a decryptable copy.
Each capability carries a status, the AWS document it came from, and a verification date. Nothing is invoked unless the interface is verified for your deployment.
Mode A (reference-only) ships on. Notification and administrative modes require a recorded Security Officer approval and an in-boundary determination.
Athena records references, statuses, and approvals about the Wickr boundary. It makes no calls to AWS at all. This is the default and the safest posture.
Athena may send sanitized, allowlisted workflow notifications toward the boundary. Payloads are scrubbed and hashed before delivery, and nothing is read back.
Athena calls the verified AWS Wickr admin API from server-side code only, to read configuration and health and to evidence readiness. Credentials never reach the browser.
The same manifest the product enforces at runtime. Only capabilities marked invocable can be called; everything else is documented, not assumed. Last verified 2026-08-05.
| Capability | Status | Invocable | Source |
|---|---|---|---|
Discover Wickr networks Returns network configuration metadata only. No message or file content is exposed by these operations. | Verified API | Yes | AWS Wickr API Reference ListNetworks / GetNetwork |
Read Wickr network settings Configuration posture only. Athena reads settings to evidence readiness; writes stay administrator-assisted. | Verified API | Yes | AWS Wickr API Reference GetNetworkSettings / UpdateNetworkSettings |
Read Wickr user directory Identity metadata only. Used to evidence named-user and device readiness items. | Verified API | Yes | AWS Wickr API Reference ListUsers / GetUser / ListDevicesForUser |
Provision and deprovision Wickr users Available, but gated behind Security Officer approval because deprovisioning is destructive to an active engagement. | Verified API | Yes | AWS Wickr API Reference BatchCreateUser / BatchDeleteUser / BatchToggleUserSuspendStatus / BatchReinviteUser |
Create and update security groups Security-group posture, including burn-on-read and federation settings, is readable and writable through the admin API. | Verified API | Yes | AWS Wickr API Reference ListSecurityGroups / CreateSecurityGroup / UpdateSecurityGroup / ListSecurityGroupUsers |
Register OIDC single sign-on Registration and a dedicated test operation both exist. The client secret must live in AWS Secrets Manager; Athena stores only a reference. | Verified API | Yes | AWS Wickr API Reference RegisterOidcConfig / RegisterOidcConfigTest / GetOidcInfo |
Microsoft Entra ID single sign-on configuration AWS documents configuring an OIDC provider such as Microsoft Entra ID for named-user sign-on. The identity provider sits outside the AWS authorization boundary and is validated separately; Athena records the registration and its test result, never the client secret. | Verified configuration | Yes | AWS Wickr Administration Guide, single sign-on configuration Console-guided or OIDC registration |
Create and manage the data retention bot Bot lifecycle is API-manageable. Athena never receives the bot challenge value or any retained content. | Verified API | Yes | AWS Wickr API Reference CreateDataRetentionBot / GetDataRetentionBot / UpdateDataRetention / DeleteDataRetentionBot |
Serverless data retention (Nitro Enclaves and a customer managed key) Wickr decrypts inside AWS Nitro Enclaves using your customer managed key and writes to an S3 bucket encrypted with that key, read through a provided decryption function. Prefer this over a self-managed container host. | Verified configuration | Yes | AWS Wickr Administration Guide, Data retention modules Console-guided setup |
CloudTrail capture of Wickr API calls Covers Wickr API and console-originated administrative calls. It does NOT cover in-application client events, so audit claims must be scoped to the control plane. | Verified configuration | Yes | AWS Wickr Administration Guide, Logging with CloudTrail CloudTrail trail |
Read Wickr message or file content from the SaaS Every message, call, and file is encrypted with a new random key and no party other than the intended recipients, including AWS, can decrypt it. Athena must never attempt to retrieve content. | Unsupported | No | AWS Wickr Administration Guide, end-to-end encryption |
Deploy a write-only Wickr bot A data retention bot exists precisely to receive all network content. There is no documented read-restricted bot, so a write-only claim cannot be made. | Unsupported | No | AWS Wickr Administration Guide, Data retention modules |
Audit in-application Wickr client events CloudTrail records API activity, not end-user client behaviour inside the Wickr application. | Unsupported | No | AWS Wickr Administration Guide, Logging with CloudTrail |
Deep link directly into a Wickr room No documented deep-link scheme. Until AWS confirms one, the product links to the Wickr application generally and names the room in text. | Pending AWS confirmation | No | Not documented as of the verification date |
FIPS-validated Wickr API endpoint Regional endpoints follow the admin.wickr.{region}.amazonaws.com pattern. A separate FIPS endpoint is not documented, so no FIPS endpoint claim may be made. | Pending AWS confirmation | No | Not documented as of the verification date |
AWS Config inspection of internal Wickr settings AWS Config can record surrounding customer resources such as the retention bucket, key, and roles, but not settings inside the Wickr network. | Unsupported | No | Not documented as of the verification date |
Authorized offering and region determination Authorization depends on the specific offering and region the customer deploys. The customer must confirm scope and attach the evidence; Athena records the determination and never asserts it. | Customer-configured | No | AWS Services in Scope of the FedRAMP program |
This document describes Athena's use of AWS Wickr as a FedRAMP-authorized component. It does not represent Athena's SaaS or Athena Consulting Group as independently FedRAMP authorized.
No. Athena does not represent Fortify-CMMC as FedRAMP authorized. Athena has intentionally architected CUI and regulated evidence out of its SaaS. For regulated engagements, AWS Wickr is used as the authorized secure-collaboration component only after the applicable offering, region, authorization scope, configuration, and supporting AWS services have been validated. CUI and regulated evidence remain within the approved Wickr and customer-controlled retention environment. Athena manages the CMMC workflow through approved metadata, external references, responsibilities, status, and sanitized conclusions. This design gives the customer a clear, defensible system boundary: regulated content stays in the approved environment, while Athena manages the work required to prepare for and sustain CMMC assessment readiness.
Sensitive evidence lives in the approved Wickr and retention boundary. Athena’s SaaS manages sanitized workflow, status, control mapping, and approved conclusions.
No. Capabilities that would read message bodies, file content, or retained-record exports are marked unsupported in the capability manifest and are refused locally, before any request is formed. The refusal is written to the boundary audit log.
The controlled retention repository is a separately configured customer component. It is not represented as FedRAMP authorized merely because AWS Wickr is authorized; its authorization boundary must be determined and documented by the customer.
Verify-before-build. An interface is only invoked once the AWS documentation for it is recorded, the per-tenant capability manifest is verified for the offering and region, and the Security Officer approval is on file.