Skip to main content
Vallark

by Accelera Solutions with SigilArk

vallark (n.), from vallum 'palisaded rampart' + ark 'vessel': a defensive perimeter that arrives ready to hold.

For .mil mobile program offices

Your mobile program, ATO-capable on day one.

In Accelera's .mil delivery experience, a mobile ATO typically takes 12+ months of compliance plumbing before the first feature can ship. Vallark is Accelera's golden-path framework that ships that floor pre-built: controls, documentation, and automated gates across every layer your program has to authorize.

ATO-capable: the controls, documentation scaffolding, and evidence pipeline an RMF package requires, implemented and CI-enforced. Authorization remains the AO's decision.

Request a capability briefing →

Accelera runs two .mil systems at IL4 in AWS GovCloud, ~5K daily active users, in production since March 2026 with ATOs held without lapse. Vallark is the floor distilled from them.

On disk today

The floor is code, not a promise.

What ships in the starter repos the day your program clones them. Every figure below is verifiable against a tagged commit of each starter repo at the capability briefing.

  • FIPS 140-3

    crypto standards mapped

    Per-target validated-module mapping across iOS, Android, web console, and API.

  • CycloneDX 1.5

    SBOM generated in CI

    Live on the iOS starter today: every build ships its software bill of materials.

  • 12

    NIST 800-53 controls documented with evidence

    Controls from the incident-response, planning, and risk assessment families, in the floor's security-controls baseline. Remaining families arrive templated in the SSP shell.

  • 16

    documented compensating controls

    Each with rationale and residual-risk statement, written for AO review rather than reconstructed at audit time.

  • 15

    risks in the NIST 800-30 assessment

    A pre-built risk assessment report your ISSO extends with program-specific rows, not authors from scratch.

  • SSP

    shell per NIST 800-18

    eMASS-compatible system security plan scaffolding covering all control families. Your program fills in the program-specific rows.

  • 90 / 85

    coverage gates in CI

    Line and security-module coverage thresholds enforced on every PR, backed by mutation testing.

  • 276

    iOS test functions

    In the iOS starter today, including the compliance gate chain that blocks release on missing evidence.

  • CUIValue⟨T⟩

    typed CUI discipline

    A compile-time wrapper with 5 compile-fail fixtures proving that CUI leaks into logs, storage, or URLs do not build.

I · Scope

Five layers. Five evidence packages.

Every .mil mobile program has to authorize a full stack, not just the app. Each layer is assessed independently and ships its own evidence package.

  • Cloud infrastructure

    Authorization boundary, SSP, continuous monitoring, FedRAMP High + DoD Cloud Computing SRG inheritance via the DISA Provisional Authorization, for CSP-responsible controls.

    AWS GovCloud · Terraform

  • Backend API

    DISA SRG + STIG coverage, SBOM, SLSA provenance, every endpoint audited, CUI classification enforced, audit trail tied to identity.

    Hono.js on AWS Lambda · API Gateway

  • Web console

    FIPS 140-3 validated-module crypto mapping, strict CSP, no client-side CUI persistence, Section 508 / WCAG AA, VPAT, sessions bound to CAC-backed identity.

    React · BFF pattern · CloudFront edge

  • iOS app

    DISA Mobile SRG, App Attest, certificate pinning, root / debugger detection, keyboard and screenshot discipline, release-build log stripping.

    Swift · iOS 16+

  • Android app

    DISA Mobile SRG, Play Integrity, certificate pinning, root / debugger detection, keyboard and screenshot discipline, release-build log stripping.

    Kotlin · Android 13+

One stack · one boundary · five evidence packages
Vallark architecture: three clients (iOS, Android, Web) converge into one backend API, which runs in a Terraform-managed AWS GovCloud environment, all inside a single ATO / STIG / FIPS 140-3 compliance boundary. ATO · STIG · FIPS 140-3 boundary iOS APP Swift · App Attest PKCE ANDROID APP Kotlin · Play Integrity PKCE WEB CONSOLE React · BFF pattern CAC / PIV BACKEND API Hono.js on AWS Lambda · Postgres · API Gateway JWT · OIDC · TRUST BROKER CLOUD INFRASTRUCTURE Terraform · AWS GovCloud · CloudFront · S3 · IAM

And the platforms aren't symmetric. iOS has no public API to prevent screenshots, so where Android writes a prevention control, iOS writes a compensating detection-and-audit control. Both rows have to be documented, tested, and defensible before one STIG control is closed.

Every server-side layer also ships in STIG-hardened RHEL-9 UBI containers, rebuilt nightly to hold a 0 / 0 / 0 / 0 scan of known fixable CVEs (critical / high / medium / low, nightly Trivy).

Built on

  • AWS GovCloud
  • Terraform
  • React
  • Hono.js
  • Docker
  • Red Hat UBI
  • Swift
  • Kotlin

II · The marathon

Why it takes 12+ months.

The work is genuinely that big, and the rigor is warranted. The question isn't whether to clear these; it's whether each program clears them from scratch.

Every friction point below is one Vallark ships already cleared.

ISSO and AO scrutiny

Mobile is the risk category cyber leadership worries about most. Every control needs evidence. Every exception needs a signed compensating-control row. Every platform gap gets questioned.

Platform-specific controls

iOS can't prevent screenshots. Android can. The same STIG row is a prevention on one platform and a compensating control on the other: both built, tested, defended. Every divergent surface doubles the matrix.

Documentation surface

SSP. POA&M. VPAT. FIPS 140-3 validation. DISA Mobile STIG checklist. App-revocation runbook. Threat model. Data inventory. CUI acknowledgment. Version-controlled to the code that implements them.

Multi-program drift

Run two .mil mobile programs and you're copy-pasting controls across codebases. Every iOS privacy change or CVE means every fork needs the patch, the re-test, the evidence update. By program three, maintenance exceeds delivery.

III · The relief

Five starter projects. One compliance floor. Day one.

Accelera brings Vallark to every .mil mobile engagement as five pre-built, ATO-capable starter projects. Your developers clone them on day one and begin building features inside a scaffold that already implements the floor's controls.

Five starter projects, day-one ready

One per target (infrastructure, API, web console, iOS, Android). Each ships with STIG / RMF controls implemented and evidence generated. Your developers clone and begin writing features inside a scaffold that implements the floor's controls.

ATO documentation baseline

SSP shell. STIG checklists. Compensating-control inventory. Threat model. Data inventory. VPAT baseline. Pre-filled to the level Vallark is implemented at. Your team adds the program-specific rows, not the framework.

Automated compliance gates

CI checks the machine-verifiable rows of the 22 + 8 control matrix on every PR and blocks release on missing evidence; the remaining rows carry documented manual test procedures in the evidence bundle. Produces the evidence bundle your ISSO reviews, the same green gate your engineers see.

One maintained baseline, every program

One baseline, updated in one place when OS APIs shift or a CVE lands. The patch lands once and propagates to every program in your portfolio. The floor stays current, without drifting copy-paste forks.

The compliance floor stops being the critical path.

Your program's first release

Month 12 → Week 4

Typical .mil mobile program

12 months → first release candidate + evidence package

With Vallark

4 weeks → first release candidate + evidence package

Weeks shown are engineering and evidence-package readiness; AO adjudication timelines are program-specific.

IV · On the device

The controls, in your hand.

Every Vallark control lands as actual UI on real iOS and Android devices. Here's what four of them look like in flight.

iOS screenshot: CUI banner + ack gate

CUI banner + ack gate

Classification banner pinned to every authenticated view, including first-launch. The CUI acknowledgment gate runs underneath, versioned so policy changes re-prompt.

Android screenshot: Login.gov in flight

Login.gov in flight

Sign-in opens the IdP in-app. Same flow for AWS Cognito, Okta, MyAuth, or any OIDC provider; the surrounding chrome doesn't change.

iOS screenshot: Root / jailbreak rejection

Root / jailbreak rejection

Launch refuses on devices showing signs of root or jailbreak. The deny screen names the cause so the user knows what's wrong.

Android screenshot: App-switcher privacy

App-switcher privacy

Backgrounded app shows a privacy screen instead of the active view. Prevents shoulder-surfing in the app-switcher carousel.

V · Identity

Pick your IdP. The flow is wired.

CAC on web. Modern IdPs across every surface. JWT / OIDC orchestration in the API. PKCE on mobile. The hardest gate in a .mil program ships pre-wired, not bolted on.

CAC on the web console

PIV smart-card auth lands in the web starter on day one: the credential most program offices ask about first. Cert chain validation, OCSP, and the middle-tier bridge to the API ship pre-wired in the starter.

IdPs out of the box

Pick your IdP per program; the surrounding flow stays uniform across surfaces. Any OIDC / PKCE provider drops in via standard configuration; the named providers below are pre-wired in the starter.

One trust broker in the API

The API starter handles the full JWT / OIDC authn and authz flow end-to-end. Web, mobile, and third-party API clients all flow through the same identity contract: one code path to audit, one place to govern.

Mobile PKCE, by default

Mobile auth has its own constraints: no client secret, redirect handling, attestation binding. The mobile starter ships PKCE wired through the trust broker so the flow is uniform across iOS and Android.

Identity providers, supported out of the box

  • Login.gov
  • Cognito
  • Okta
  • Auth0
  • MyAuth
  • Any OIDC / PKCE

VI · Proven in production

Already shipping. Already authorized.

Accelera ships and operates two .mil systems in production today, on IL4 GovCloud, in continuous production since March 2026. Vallark is the compliance floor distilled from them.

Tactical-edge training and exercise platform

IL4 GovCloud Real-time multiplayer

Multiplayer iOS, Android, and web clients coordinated over real-time WebSocket. In-game interrupts, gameplay replays, and after-action review across concurrent mission scenarios. Hono.js API on AWS Lambda; Postgres for state.

Medical-readiness system

IL4 GovCloud Offline-capable

iOS and Android provider apps with offline mission editing and deferred sync. Drag-and-drop editor pushes updates to every device. Command-level console with readiness dashboards serving military, international, and disaster-relief engagements. Hono.js on AWS Lambda; Postgres for state. Offline persistence runs under the floor's documented allowlist exception with FIPS-validated encryption at rest.

~5K

Daily active users, both systems

Mar 2026

In production since

IL4

Operating level, AWS GovCloud

ATOs held without lapse by both systems under their respective Authorizing Officials. Nightly Trivy CVE and STIG-configuration scans, with findings remediated by automated rebuilds of Glyphon-managed UBI 9 containers. Both systems implement the full 22 + 8 control matrix that the floor ships out of the box.

The controls, documentation, and gates they run on are packaged so the next program starts where they finished.

Program identities, authorization evidence, and government references are available under NDA at the capability briefing.

See the full 22 + 8 control matrix ↓

VII · The control set

22 full-parity · 8 platform-specific

Every control in the floor, mapped to its citation.

The 22 + 8 matrix, proven in the production systems above, extends the native-mobile control set across the web console and the API surface, so mobile controls are load-bearing end-to-end. Each control below maps to the publication or specification that informs it. Each row carries an 800-53 Rev 5 / CCI crosswalk in the evidence bundle.

Coverage at a glance

30 controls × 4 platforms. 104 cells apply (99 full implementations plus 5 compensating postures); the rest are platform-asymmetric by design.

The floor's 16 documented compensating controls cover the 5 compensating cells below plus the per-target exceptions enumerated here.

View all 16 compensating controls
  1. Platform-limitation controls (5)

    • C1 Screenshot prevention (Web): a CUI-marker overlay, CSP frame-ancestors 'none', and a visibilitychange audit event compensate for the browser's lack of a FLAG_SECURE equivalent.
    • C2 Clipboard clearing (iOS): the pasteboard is cleared on sign-out and background transition via public API; content the platform puts out of reach (a suspended app, other apps' writes) is covered by a user notice and the documented residual risk.
    • C3 Copy/cut suppression (iOS): a UIViewRepresentable wrapper attempts best-effort menu suppression on CUI text fields, backed by a CUI banner and a client-side audit event on detectable copy attempts.
    • C4 Code obfuscation (iOS): release-build symbol stripping (STRIP_INSTALLED_PRODUCT, DEPLOYMENT_POSTPROCESSING) compensates for the absence of an R8/ProGuard equivalent on Swift; adopters with elevated threat models layer commercial obfuscation.
    • C5 Certificate pinning (Web): HSTS preload, Expect-CT reporting, optional mTLS on the BFF-to-API leg, and SRI on third-party CDN assets compensate for the browser CA-store model that makes client-side cert pinning infeasible.
  2. Crypto and FIPS scope (4)

    • C11 Browser crypto FIPS scope: all FIPS-scope cryptography is handled server-side in the BFF and API tier; the browser performs only non-security-critical operations (file deduplication hashing) that are never authoritative identity or integrity signals.
    • C12 ChaCha20-Poly1305 cipher: the API tier disables ChaCha20-Poly1305 at TLS termination via API Gateway and ALB cipher-suite policy, so FIPS-boundary connections negotiate AES-256-GCM only.
    • C13 Argon2id pre-standardization: Argon2id is deployed under explicit compensating-control acceptance pending NIST SP 800-132 Rev 1 finalization; legacy PBKDF2 entries retire within 12 months of adoption.
    • C14 OpenSSL FIPS 140-2 sunset: the API tier is tracked against CMVP status monthly with a remediation plan to migrate to an OpenSSL version carrying an active FIPS 140-3 validation before the 2026-09-21 sunset date.
  3. Supply chain and policy (4)

    • C6 Crash/RUM SDK exclusion: a built-in minimal crash handler with a Vallark-owned ingest endpoint compensates for the intentional exclusion of closed-source third-party crash and RUM SDKs from the supply chain.
    • C8 CVSS exceptions: each Critical or High CVE that cannot be patched within SLO receives a row in the CVSS exceptions sub-table with a mandatory expiration date; CI fails when an expiration passes without resolution.
    • C9 Android secure-defaults overrides: each allowBackup=true or exported=true override receives a per-component entry in the Android secure-defaults overrides sub-table with an explicit STIG justification and scope limitation.
    • C10 Provisioned-concurrency (low-DAU): for programs below 100 DAU, an SLO downgrade accepting cold-start tail latency on attestation and auth endpoints compensates for provisioned-concurrency cost being infeasible.
  4. Accessibility and operational (3)

    • C7 Assistive-technology audio (Section 508): a configurable CUI warning modal on first AT-detected use and environment-tunable policy text compensate for the legal prohibition on disabling screen-reader output for assistive-technology users.
    • C15 Attestation log-only (Phase 1): during the first 2-4 weeks per adopter, attestation runs in log-only mode; every attempt and verdict is captured in the immutable audit stream and reviewed weekly before escalating to Phase 2 (soft enforcement) and Phase 3 (hard enforcement).
    • C16 Break-glass self-approval at N=1: every self-granted break-glass event emits a self_grant_declaration meta-event; post-facto ISSO review occurs within tier-specified windows; a frequency cap of four self-grants per month at the two highest break-glass tiers triggers the move to a three-person approval triad before break-glass becomes routine.
Control
  • 01 Root / jailbreak detection
  • 02 Debugger detection
  • 03 Device attestation
  • 04 Attestation header injection
  • 05 CUI // OPSEC banner
  • 06 CUI banner regression test
  • 07 Keyboard caching disabled
  • 08 CUI acknowledgment gate
  • 09 Gate chain order
  • 10 Token lifecycle: 120s background grace
  • 11 In-memory-only tokens
  • 12 Certificate pinning
  • 13 Disk cache disabled
  • 14 30-second request timeouts
  • 15 Version headers
  • 16 Bearer token injection
  • 17 Session-expired (401) handler
  • 18 Upgrade-required (426) handler
  • 19 Attestation-failed (403) handler
  • 20 Disk-write regression test
  • 21 Interceptor registration regression test
  • 22 OIDC provider abstraction
  • 23 Screenshot prevention or detection
  • 24 App-switcher / task-preview privacy
  • 25 Copy / cut disabled on CUI fields
  • 26 Clipboard clearing on sign-out / background
  • 27 Build-time log stripping
  • 28 CUI logging regression test
  • 29 Play Integrity (Android)
  • 30 App Attest (iOS)
Applies Compensating Not applicable

Full-parity controls · 22

Controls that ship with matching implementations, or a documented compensating posture, on every surface where the control applies.

View all 22 full-parity controls
02

Debugger detection

Detect attached debuggers at launch and prevent debugger attachment on release builds.

04

Attestation header injection

Every authenticated mobile request carries X-Attestation-Token; omitted from web requests by design under the BFF model.

Android iOS API
05

CUI // OPSEC banner

Classification banner visible on every authenticated view; banner text configurable to the marking your program requires.

06

CUI banner regression test

Static source-walk in CI asserts every screen renders the banner. Prevents silent drift on new routes.

Android iOS Web API
07

Keyboard caching disabled

Autocorrect, predictive text, personalized-learning, and autofill suppressed on fields handling CUI.

08

CUI acknowledgment gate

First-launch modal reminds users of CUI handling obligations. Versioned so policy changes re-prompt.

09

Gate chain order

Fixed precedence: jailbreak → CUI ack → auth → upgrade check → attestation → app. Compiled-in; no runtime toggles.

Android iOS Web API
10

Token lifecycle: 120s background grace

App tokens wiped 120 seconds after backgrounding. Cold start forces OIDC re-authentication.

Android iOS Web API
11

In-memory-only tokens

Refresh and access tokens never touch disk: no Keychain, no SharedPreferences, no localStorage.

Android iOS Web API
12

Certificate pinning

Release builds pin the API TLS certificate; backup pin enables rotation overlap; pin failure is a hard error.

Compensating on web: browser CA store + HSTS + CT logs per standard web posture.

Android iOS Web API
13

Disk cache disabled

HTTP disk cache off by default; CUI responses additionally tagged Cache-Control: no-store.

Android iOS Web API
14

30-second request timeouts

Every client and the API gateway enforce a 30-second cap. No unbounded waits on any path.

Android iOS Web API
15

Version headers

Every authenticated request carries X-App-Version and X-Platform-Version. Server audit-logs both and enforces a minimum-version floor.

Android iOS Web API
16

Bearer token injection

Authorization: Bearer <jwt> added server-side by the BFF for web, client-side for mobile. Validated at the API on every route.

17

Session-expired (401) handler

Client intercepts 401 + RFC 7807 code=session_expired, surfaces an explicit re-auth flow, never a silent retry loop.

18

Upgrade-required (426) handler

Server returns 426 when X-App-Version is below floor. Client shows a non-dismissable update prompt.

Android iOS Web API
19

Attestation-failed (403) handler

Client intercepts 403 + RFC 7807 code=attestation_failed, triggers a re-attestation flow rather than crashing.

20

Disk-write regression test

CI fails if any code path writes to disk outside an explicit allowlist. Catches persistence regressions before they ship.

Android iOS Web API
21

Interceptor registration regression test

CI verifies all required middleware and client interceptors are registered in the correct order.

Android iOS Web API

Platform-specific controls · 8

Controls where the ideal implementation differs per target, or where one platform's API surface forces a compensating posture.

View all 8 platform-specific controls
23

Screenshot prevention or detection

Android blocks screenshot capture at the platform window level. iOS and web detect the event and audit it; those platforms do not expose a prevention API.

Compensating on iOS (detect-only) and web (detect-only via visibilitychange).

Android iOS Web API
24

App-switcher / task-preview privacy

Thumbnail obscured when the app is backgrounded. Secure-window flag on Android, material blur overlay on iOS.

25

Copy / cut disabled on CUI fields

CUI

Android suppresses the text-toolbar copy/cut items. Web blocks copy and cut events on CUI inputs. iOS is best-effort with no public API.

Compensating on iOS: no public SwiftUI API to suppress text-toolbar items.

26

Clipboard clearing on sign-out / background

CUI

Android calls ClipboardManager.clearPrimaryClip() on sign-out and background transitions.

Compensating on iOS: the pasteboard is cleared on sign-out and background transition via public API; it cannot be cleared once the app is suspended and cannot cover other apps' writes, so detection and audit complete the posture.

27

Build-time log stripping

Release builds strip debug logs: R8 -assumenosideeffects on Android, os.Logger scoping on iOS, Vite in web production, Pino log-level pinned on API.

Android iOS Web API
28

CUI logging regression test

CUI

Per-platform lint rules (detekt-no-cui-in-log, swiftlint-no-cui-in-log, eslint-no-cui-in-log) plus source-walk tests catch CUI leaking into logs.

29

Play Integrity (Android)

Hardware-backed attestation via Google Play Integrity API. Server verifies verdict, nonce, and device-integrity fields on every attested request.

Vallark boar mascot

For any engagement where Accelera is on the team, prime or teammate, this matrix lands on day one.

by Accelera Solutions with SigilArk

Request a capability briefing →