Product factsheet · Defense & Intelligence · Moraph software

Cryptographic Key Management System (CKMS)

The Cryptographic Key Management System keeps the record of keying material for radios, weapon systems and other end cryptographic units: where each key came from, who holds it, which devices it was loaded into, and when it was superseded or destroyed. It runs the requests, hand receipts, loading records and destruction reports that COMSEC accounts work through every day. When a key is reported compromised, it shows every holder and device affected and drives the emergency supersession steps your controlling authority directs.

Product page

Principal workflows

  • Receive and generate: Keying material enters the account either from your government key management infrastructure, recorded on receipt, or, for unclassified and commercial keys within the system's scope, generated in a FIPS 140-3 validated hardware security module you designate.
  • Distribute and load: Units request key through the system, the account manager issues it on a hand receipt, and key operators record which devices it was loaded into, so the account always knows where each key is in use.
  • Supersede and destroy: The system counts down to each supersession date, reminds holders to rekey and destroy, and keeps the destruction record with its witness, so nothing stays in use or on hand past its date.
  • Respond to a compromise: When key is reported lost or compromised, the system identifies every holder and device that has it, records the report, and tracks each holder through the emergency supersession steps the controlling authority directs.

Who uses it

  • COMSEC account managers and their alternates
  • Hand receipt holders and key operators in units and on platforms
  • Controlling authorities who direct key use, supersession and emergency rekey
  • Information system security managers responsible for cryptographic equipment
  • Inspectors and auditors who review COMSEC accounts

Reporting

  • Account inventory by holder, device and accounting legend
  • Supersessions coming due and material overdue for destruction
  • Open key requests and their status
  • Compromise incidents and holders still to confirm rekey
  • Inventory reconciliation results and discrepancies
  • Destruction reports prepared and submitted

Features

  • Account inventory: Every item of keying material on the account, with its short title, edition, accounting legend, location, holder and supersession date.
  • Key requests: Units request key for named devices, nets or missions, and the account manager approves, issues or returns each request with a reason.
  • Electronic hand receipts: Material issued to local holders is signed for electronically, and transfers between holders are recorded rather than handed over on paper.
  • Device load records: Each load into a radio, weapon system or other end cryptographic unit is recorded against the device serial number, so you can see which key is in which device.
  • Supersession tracking: Upcoming supersession dates by holder and device, with reminders to rekey and destroy before material goes out of date.
  • Destruction records: Zeroization and destruction recorded with the destroying official, the witness and the method, and assembled into destruction reports for submission.
  • Compromise response: A compromise report immediately lists every holder and device with the affected key and tracks each through the directed supersession steps until all have confirmed.
  • Two-person integrity: Steps your procedures mark for two-person integrity, such as receipt or destruction of certain material, cannot be completed until a second authorized person confirms.
  • Inventory and reconciliation: Periodic and change-of-custodian inventories are run from the system, with each item confirmed by the holder and discrepancies recorded for resolution.
  • Key generation for commercial keys: Unclassified and commercial symmetric and asymmetric keys can be generated, wrapped and distributed through a FIPS 140-3 validated hardware security module you designate.
  • Device registry: End cryptographic units and fill devices registered with their type, serial number, assigned unit and status, including devices in maintenance or awaiting disposal.
  • Inspection-ready audit trail: Every receipt, issue, transfer, load, destruction and report recorded with the person and time, and exportable for inspectors and auditors.

Integrations

  • Government key management infrastructure: Records of material received from your government key management infrastructure are imported or entered on receipt, and reports are prepared in the form your infrastructure requires, for your account manager to submit.
  • Hardware security modules: Unclassified and commercial keys are generated and wrapped in a FIPS 140-3 validated hardware security module you own and designate; key values never appear in the application.
  • Fill device records: Where your fill devices can export load logs, those logs are imported to confirm device loads instead of entering them by hand.
  • Property and maintenance systems: Device serial numbers, assigned units and maintenance status from your property book or maintenance system keep the device registry current.
  • Single sign-on: Users sign in through your identity provider, including smart-card (PKI) sign-in where your environment uses it.
  • Security information and event management: The audit trail is streamed to your SIEM so security staff see account activity alongside other events.
  • Work API: Holdings, requests, supersession schedules and incident status available to your own reporting tools through the Moraph Work API, inside your environment.

Deployment

  • Client-hosted on your networks: Installed in your environment, including classified networks, and operated under your authority and within your own authorization.
  • Disconnected and tactical sites: Local instances at sites with limited connectivity record holdings and loads offline and synchronize with the account when a connection is available.
  • Moraph cloud, United States: For unclassified commercial key inventories, available hosted in Moraph's United States region where your policy allows.
  • With a managed service: Optionally supported by a Moraph managed service for administration and integration upkeep, with staff who hold the clearances your environment requires.

Security and privacy

  • No key values in the application: The system records identifiers, holdings and events. Key values stay in the hardware security module, fill devices and end cryptographic units, never in the application database.
  • Single sign-on and role-based access: Users sign in through your identity provider, and what each person can see and do follows their role and account; issuing key is separate from approving its use.
  • Two-person integrity: Actions your procedures require two people for are enforced by the system, and both identities are recorded.
  • Encryption and keys: Records are encrypted at rest and in transit, with keys Moraph staff cannot use without explicit, time-bound authorization.
  • Complete audit trail: Every view, change, issue, load, destruction and report is logged with the person and time, and cannot be edited.
  • Your authority, cleared support: On classified networks the system is installed and operated under your authority. Support tickets for defense and intelligence clients are handled only by US citizens with active clearances.

Limitations

  • It does not produce government-issued keying material. Keys for national security systems come from your government key management infrastructure; the system accounts for them but does not replace that infrastructure.
  • Key generation is limited to unclassified and commercial keys, generated in a FIPS 140-3 validated hardware security module that you provide and designate.
  • Moraph does not claim accreditation or authorization of the system for any classified environment. Use on classified networks requires your organization's own authorization and is operated under your authority.
  • It does not load key into devices or zeroize them. People do that with fill devices and the equipment itself; the system records it.
  • Revocation after a compromise depends on people acting on the controlling authority's direction. The system shows who must act and tracks confirmation, but cannot reach into devices to remove key.
  • Reports to your government key management infrastructure are prepared for your account manager to submit; the system does not submit them on your behalf.
  • The accuracy of holdings depends on loads, transfers and destruction being recorded when they happen, especially at disconnected sites that synchronize later.
  • It is not a COMSEC incident reporting authority. Decisions about whether an incident occurred and what it requires belong to your controlling authority and the officials your procedures name.

Next steps

Book a demonstration or a technical briefing at www.moraph.com/solutions/cryptographic-key-management-system-ckms. Purchasing routes and company information: www.moraph.com/how-to-buy.

Moraph LLC · Current as of October 2026.