Showing all phase content; selected phase is highlighted in section badges.

Roadmap

As-of: 2026-05-09. Roadmap reviewed: 2026-05-09. Next review: 2026-06-09.

Source: codebase state, manifest.yaml, appsettings-staging.json, appsettings-prod.json, project conversation history.


Now — v1 (Staging Pilot)

Goal: Demonstrate the governance-first credential issuance pattern end-to-end in a controlled environment. Validate that the architecture, policy engine, and Keeper integration hold up under real (if limited) use.

Current state as of 2026-05-09:

  • Staging deployed and healthy (app-passkey-stg-ben-6b2f, /healthz 200).
  • Keeper trial active (12-day window from provisioning — expiry imminent).
  • Vault mode: staging (KSM reads live vault, Commander shares stubbed).
  • Governance gate: HARDEN_GOVERNANCE_v1=false (soak mode).
  • Bot not registered — Teams notification flow is skeleton only.
  • 33 backend test files passing.
  • Frontend test runner not wired.

Key Components:

ComponentStatusNotes
Backend (Express + Prisma + Postgres)DeployedAll core services, policy engine, 6 background jobs
Frontend (React + Fluent UI 9)DeployedFull UI, embedded in App Service static serve
Entra ID authenticationWorkingJWT validation against configured tenant
KSM vault readsWorkingReal reads in staging via RealVaultReadService
Commander vault sharesStubbedStubVaultShareService — logs intent, returns synthetic result
Policy engine (6 rules)WorkingPure evaluator, decision traces persisted
Governance authority model (INV-1)WorkingAppend-only, DB trigger enforced
Audit trail (27 actions + decision traces)Working
Issuance token exchange (INV-5)Working (code)Not exercised in true mode on staging

Dependencies: None external — v1 is self-contained on staging.

Estimated Effort: Complete (v1 is shipped to staging).

Risks:

  • Keeper trial expires before integration validation completes.
  • HARDEN_GOVERNANCE_v1 has never been tested in true mode.
  • No production path yet.

Decision Owner: Ben (engineering).


Next — v3 (Production Hardening)

Status: Scope not locked. The items below represent the expected minimum for a production-ready deployment. Several require PO/CTO input before work begins.

Goal: Deploy to production with full Keeper integration, Teams notifications, and hardened governance gate. Establish the system as a reliable, production-grade service.

Key Components:

ComponentStatusDecision Needed?
Production App Service deploymentNot startedYes: SKU tier (S1 vs P1V2), custom domain, SSL cert
VNet + NAT Gateway + private endpointsNot startedYes: Network topology approval
Keeper trial → paid conversionNot startedYes: License tier, seat count, budget approval
KSM Application IP lock fixNot startedNo — operational task (uncheck or recreate)
KSM folder grants in Keeper ConsoleNot startedNo — operational task
Commander in full mode (live shares)Not startedDepends on Keeper licensing
HARDEN_GOVERNANCE_v1=trueNot startedNo — but requires staging validation first
Bot Framework registrationNot startedYes: M365 admin approval, bot identity owner
Teams Adaptive Card notifications (real)Not startedDepends on bot registration
Frontend test runner (vitest)Not startedNo
Discovery strategy finalization (UID-pinned)Not startedYes: Reset vs. reconcile hand-linked SQL
Dedicated Postgres databaseNot startedNo — operational task
Baseline Prisma migrationNot startedNo
Prod appsettings-prod.json completionNot startedDepends on Entra registration for prod
Monitoring + alerting baselineNot startedYes: SLA targets, alert thresholds

Dependencies:

  1. Keeper licensing decision (blocks Commander full mode and any live share testing).
  2. M365 admin approval (blocks bot registration).
  3. Production Entra app registration (blocks prod auth).
  4. CTO approval for production infrastructure spend (~$220–260/mo, see Cost Model).

Estimated Effort: 80–125 engineering hours (see Cost Model).

Risks:

  • Scope creep if v3 isn’t explicitly bounded.
  • Keeper licensing negotiation timeline unknown.
  • M365 admin approval timeline unknown.

Decision Owner: CTO (scope lock), Ben (execution).


Later — v4 (SMS Android MFA)

Status: Conceptual. All items are assumptions, not commitments.

Goal: Add SMS-based OTP as a second factor for credential retrieval. Strengthen the issuance token exchange with device-bound verification.

Key Components:

ComponentNotes
SMS gateway integrationAzure Communication Services or Twilio. Decision needed.
Two-step issuance flowChallenge + OTP verification before share URL delivery
ChallengeEvent schema modelNew table for OTP challenge audit
challenge.service.tsNew service for OTP generation, delivery, verification
Android companion app (option A)If device-bound MFA is required beyond SMS
Standard SMS delivery (option B)If SMS-only is acceptable for MVP
Threat model updateSIM swap, SMS interception, OTP replay analysis

Dependencies:

  1. v3 production deployment complete.
  2. SMS gateway vendor decision.
  3. Companion app vs. SMS-only decision.
  4. Security review of SMS threat surface.

Estimated Effort: 70–220 engineering hours (range depends on companion app decision).

Risks:

  • SMS is not a strong second factor (SIM swap, SS7).
  • Companion app adds significant Android development scope.
  • May need to revisit if Keeper adds native MFA for share retrieval.

Decision Owner: CTO (commit vs. defer).


Out of Scope

The following are explicitly not planned for any current phase:

ItemReason
Multi-tenant supportv1–v4 are single-tenant. Multi-tenant requires schema partitioning, per-tenant vault config, and significant architectural changes.
Self-hosted / on-premise deploymentAzure-only. The architecture assumes Azure platform services (App Service, Key Vault, Postgres Flexible Server).
Non-Keeper vault backendsThe IVaultReadService / IVaultShareService interfaces are designed for swap-in, but no alternative implementation is planned.
Mobile-native app (iOS/Android) for portal UIThe React frontend is responsive but not a native app. v4’s Android scope is limited to MFA companion, not the full portal.
Real-time credential rotationThe system detects rotations (via vault-sync.job.ts) but does not trigger them. Rotation is a Keeper-side operation.
SAML / non-Entra identity providersAuthentication is Entra-only. SAML or other IdP support would require a new identity service implementation.
Offline / air-gapped operationRequires Azure platform services and network access to Keeper.
Automated SOC 2 / HITRUST certificationThe system is designed to align with these frameworks but certification requires external audit.