Cross Domain Solution Key Management and Credential Handling: Designing Crypto Boundaries for Secure Release

A cross domain solution sits at the intersection of two or more security domains, and everything it does depends on the integrity of the cryptographic layer underneath it. Policy filters, content inspection engines, and audit pipelines are only as trustworthy as the keys and credentials that protect them. When that cryptographic foundation is poorly designed, inconsistently managed, or inadequately governed, the entire security posture of the solution degrades regardless of how well the rest of the architecture is built.

Cross domain solution key management is not simply a matter of generating certificates and storing them somewhere accessible. It involves designing a trust hierarchy that spans classification boundaries, isolating management plane credentials from operational traffic, enforcing separation of duties across personnel who may hold different clearances, and maintaining audit evidence that satisfies both the authorizing official and the operational security team. Each of those requirements introduces friction that generic PKI guidance does not address.

Federal and DoD deployments add additional constraints. Key material that crosses or touches a classification boundary must be handled under controls that reflect the sensitivity of the higher domain. Hardware security modules must be positioned to protect key operations without creating single points of failure that could halt cross-domain data flows. Certificate revocation must be operationally viable even when one domain loses connectivity. These are not theoretical concerns. They surface during accreditation reviews, during operational incidents, and during sustainment cycles when the original implementation team is no longer available.

This article addresses the cryptographic trust layer specifically as it applies to CDS environments. It covers key hierarchy design, HSM placement and administration, credential isolation, split knowledge and dual control, certificate authority integration, rotation and revocation procedures, emergency recovery, and how these controls map to federal assurance and RMF expectations. The goal is to give practitioners a working framework for designing and governing crypto boundaries that hold up under operational conditions, not just during the initial accreditation.

Designing the Cryptographic Trust Hierarchy for a CDS Environment

A CDS does not operate within a single trust domain. It mediates data flows between domains with different classification levels, different certificate authorities, and potentially different cryptographic standards. The trust hierarchy must account for all of those relationships simultaneously, and it must do so in a way that does not allow a compromise in one domain to propagate trust material into another.

The starting point is mapping the certificate authorities that govern each domain. In federal and DoD environments, this typically means identifying which domain-specific PKI issues device certificates, which CA issues administrator credentials, and whether a cross-domain trust anchor exists or needs to be established. The CDS itself will need certificates from one or both domain PKIs depending on how it authenticates to components on each side. Each of those certificate relationships must be explicitly documented and approved as part of the system security plan.

Key hierarchy design for a CDS should follow a tiered model. Root and subordinate CA relationships must be clearly defined, with the CDS device certificates issued from subordinate CAs that are scoped to the appropriate domain. Shared root trust between domains is generally not appropriate unless the program has explicit authorization and the trust relationship is bounded by policy constraints. In most DoD deployments, each domain maintains its own root of trust, and the CDS is configured to validate certificates independently per domain rather than relying on a shared chain.

Symmetric keys used for data-in-transit protection across the CDS boundary require separate treatment. These keys must be generated, distributed, and stored under controls that reflect the sensitivity of the data they protect. Key wrapping, key derivation, and key agreement protocols must be selected based on the assurance level required for the boundary, not simply based on what the CDS hardware supports by default. Programs that accept default key configurations without reviewing them against their security requirements frequently discover gaps during assessment that require rework.

Trust establishment between domains is a deliberate, documented act. It should not happen as a side effect of certificate installation. The program office, the authorizing officials for both domains, and the CDS administrator team should all have explicit visibility into what trust relationships exist, what they authorize, and under what conditions they can be revoked. That documentation becomes critical during incident response and during periodic reviews.

HSM Placement, Administration, and Operational Continuity

Hardware security modules protect key material from extraction and provide a tamper-evident boundary for cryptographic operations. In a CDS environment, the question of where to place HSMs is not purely a security question. It is also an operational continuity question, because the HSM is in the critical path for key operations that the CDS depends on to function.

The most common placement pattern positions the HSM on the high-side management network, where it protects the most sensitive key material and is accessible only to personnel with appropriate clearance. This is appropriate when the primary cryptographic operations are high-side originating. However, it creates a dependency: if the HSM becomes unavailable, the CDS may lose the ability to perform key operations, which can halt data flows or prevent administrator authentication. Redundancy planning for the HSM must be part of the initial architecture, not an afterthought.

Some deployments require HSMs on both sides of the boundary, particularly when each domain has independent key management requirements and the program cannot accept a single HSM serving both. In that configuration, the key material on each side remains isolated, and the HSM administration procedures must be documented separately for each domain. Personnel who administer the low-side HSM should not have administrative access to the high-side HSM, and that separation must be enforced through both access controls and physical procedures.

HSM Administration Controls

HSM administration requires its own credential management discipline. The HSM security officer role, the HSM administrator role, and the audit role should be held by different individuals. Many programs assign all three roles to the same person because of staffing constraints, which eliminates the separation of duties that the HSM is designed to enforce. This is a recurring finding in assessments and one that is difficult to remediate after the fact without restructuring the administrative model.

HSM initialization and key ceremony procedures must be documented and executed under dual control. The key ceremony record should capture who was present, what key material was generated or loaded, what the key custodian assignments are, and how the recovery material was secured. That record is an audit artifact that assessors will request, and it must be accurate. Programs that reconstruct key ceremony documentation after the fact create audit risk that is difficult to explain.

Credential Isolation and Management Plane Separation

Administrator credentials for a CDS are among the most sensitive credentials in a multi-domain environment. A compromised CDS administrator account can potentially alter filter rules, disable logging, or manipulate the trust configuration of the solution. Credential isolation is not optional, and it requires more than strong passwords and MFA.

The management plane of a CDS should be physically or logically separated from the data plane. Administrator access should traverse a dedicated out-of-band management network that is not shared with operational traffic. This separation ensures that a compromise of the data plane does not automatically provide access to the management interface, and it limits the blast radius of a credential compromise.

Credential vaulting for CDS administrator accounts must be domain-aware. A vault that stores both low-side and high-side administrator credentials without enforcing domain-based access controls creates a path by which a low-side credential compromise could expose high-side credentials. The vault configuration should enforce that personnel with low-side clearances can only retrieve low-side CDS credentials, and that high-side credentials require high-side authentication to access. This is a configuration requirement that must be validated, not assumed.

Privileged access workstations used to administer the CDS should be dedicated to that purpose and should not be used for general browsing, email, or other activities. In practice, many programs share administrative workstations across multiple systems because of equipment constraints. When that happens, the risk profile of the CDS administrator credential expands to include every system that workstation touches. The program office should document the workstation configuration and the associated risk acceptance if dedicated workstations are not feasible.

Split knowledge and dual control requirements apply to the most sensitive credential operations, including initial provisioning of CDS administrator accounts, recovery of locked accounts, and any operation that modifies the trust configuration of the solution. These controls must be enforced procedurally and, where the platform supports it, technically. Platforms that allow a single administrator to perform all of these operations without a second approver create a control gap that is difficult to compensate for through other means.

For programs that rely on Cross Domain Solutions (CDS) to move data between classified and unclassified networks, the credential isolation architecture is often the least mature component of the deployment. It receives less attention than the filter configuration and the audit logging setup, but it represents a significant attack surface if not properly designed.

Key Rotation, Certificate Revocation, and Lifecycle Governance

Key and certificate lifecycle events in a CDS environment require coordination across security teams that may operate under different command authorities, different change management processes, and different maintenance windows. That coordination overhead is the primary reason lifecycle governance fails in practice. The technical procedures exist, but the organizational process to execute them reliably does not.

Certificate rotation for CDS device certificates must be planned well in advance of expiration. A CDS that loses a valid device certificate may fail to authenticate to domain components, which can halt data flows without warning. Programs should track certificate expiration dates in a configuration management system and assign ownership for renewal to a specific individual or team, not to the program generically. Generic ownership means no one acts until the certificate expires.

Symmetric key rotation schedules should be defined in the system security plan and tied to a specific trigger, either time-based or event-based. Time-based rotation is easier to plan and audit. Event-based rotation, triggered by personnel changes, suspected compromise, or system modifications, requires a defined response procedure that can be executed under operational pressure. Both types of rotation must be tested before they are needed.

Revocation Across Domain Boundaries

Certificate revocation is one of the most operationally problematic areas in CDS deployments. Standard revocation mechanisms, including OCSP and CRL distribution points, assume network connectivity to the CA. In a CDS environment, the network paths between domains are restricted by design, and those restrictions frequently block the revocation checking traffic that the CDS needs to validate certificates from the other domain.

Programs must explicitly test revocation checking across domain boundaries during integration testing, not during accreditation. The test should include both the normal revocation check path and the behavior when the revocation service is unreachable. If the CDS is configured to fail open when revocation checking fails, that is a security finding. If it is configured to fail closed, that is an availability risk that must be documented and accepted. Neither outcome is automatically correct; the program must make a deliberate decision and document the rationale.

Emergency revocation procedures must be documented for scenarios where a CDS administrator credential or a CDS device certificate is suspected to be compromised. The procedure should specify who has authority to initiate revocation, how the revocation is executed across both domains, what the operational impact will be, and how the CDS is restored to service after the compromised material is replaced. Programs that have not pre-coordinated this procedure with both domain security teams will improvise during an incident, which increases both the response time and the risk of error.

Audit Evidence and RMF Alignment for Crypto Controls

Cryptographic controls in a CDS environment generate audit requirements that span multiple control families. Key management activities touch IA controls, access control requirements, audit and accountability requirements, and configuration management requirements simultaneously. Programs that treat crypto audit evidence as a single artifact rather than a cross-cutting concern frequently produce incomplete packages that require significant rework during assessment.

The audit log configuration for the CDS must capture cryptographic events explicitly. Certificate validation events, key usage events, HSM access events, and administrator authentication events should all be logged with sufficient detail to reconstruct the sequence of operations during an incident investigation. Log retention must reflect the sensitivity of the data the CDS handles, and the logs themselves must be protected from modification by the administrators whose actions they record.

RMF control selection for CDS crypto controls should be driven by the actual key management architecture, not by a generic baseline. Programs that apply a standard moderate or high baseline without reviewing whether the selected controls address CDS-specific key management risks frequently have gaps in areas like key establishment, key storage, and cryptographic module validation. The ISSO and the system architect should review the control set together against the actual key hierarchy design to identify those gaps before the assessment.

FIPS 140 validation status of the cryptographic modules used in the CDS, including the HSM, the CDS platform itself, and any software cryptographic libraries, must be documented and current. A module that was FIPS validated at the time of initial accreditation may have had its validation expire or may have been superseded by a newer version with a different validation status. Tracking cryptographic module validation status is a sustainment task that must be assigned to a specific owner, not left to periodic discovery.

Key custodian assignments must be documented and kept current. When a key custodian separates from the program, the key material they held responsibility for must be transferred to a new custodian under documented dual control procedures. Programs that do not maintain current custodian records discover the gap when they need to execute a key recovery or rotation and cannot identify who holds the recovery material.

Common Mistakes

The most persistent mistake in CDS key management is treating the cryptographic layer as a configuration task rather than an architecture decision. Programs that defer key hierarchy design until late in the implementation cycle frequently discover that the default configuration does not meet their security requirements and that changing it requires significant rework. Key hierarchy design should happen during the requirements phase, not during system integration testing.

Assigning all HSM roles to a single administrator is common in programs with small security teams. It eliminates the separation of duties that the HSM is designed to enforce and creates a single point of failure for key operations. The program may document the role separation in policy while the actual configuration assigns all roles to one account. Assessors check the technical configuration, not just the policy document.

Programs frequently fail to test revocation checking across domain boundaries before accreditation. The assumption is that if revocation works within each domain, it will work across the boundary. That assumption is wrong in most restricted-path CDS environments. The test must be explicit, and the results must be documented.

Certificate expiration tracking is often informal. Expiration dates are noted during initial deployment and then not tracked systematically. When the certificate expires, the CDS fails in ways that are not immediately obvious to operators, and the root cause takes time to identify. A configuration management entry with an assigned owner and a notification trigger is not a complex requirement, but it is one that many programs skip.

Emergency revocation procedures are written but not coordinated. The procedure document exists in the SSP, but the security teams for both domains have never reviewed it, the approval chain has never been tested, and the personnel named in the procedure may have changed. A procedure that has not been coordinated and tested is not a control. It is documentation that creates a false sense of readiness.

Programs also routinely underestimate the sustainment burden of crypto controls. Key management requires ongoing attention: custodian records must be maintained, rotation schedules must be executed, FIPS validation status must be tracked, and audit logs must be reviewed. When the implementation team transitions off the program, that institutional knowledge often leaves with them. The sustainment team inherits a system they did not build, with crypto controls they do not fully understand, and documentation that may not reflect the actual configuration.

Recommended Federal Approach

Start with a crypto architecture review before any hardware is procured or configured. The review should map the certificate authorities for each domain, define the key hierarchy, identify the cryptographic modules that will be used, and establish the separation of duties model for key and credential administration. This review should involve the ISSO, the system architect, and the security teams for both domains. The output is a documented crypto architecture that becomes part of the SSP and drives all subsequent configuration decisions.

Define HSM placement and redundancy requirements as part of the architecture review, not after deployment. Identify whether a single HSM or domain-separated HSMs are required, where each HSM will be physically located, how redundancy will be achieved, and what the maintenance procedure will be for firmware updates and key operations that require the HSM to be offline. Document the operational impact of HSM unavailability and get that impact accepted by the mission owner before deployment.

Execute the key ceremony under documented dual control before the system is placed into operation. The ceremony record should be treated as a formal audit artifact and stored in a location that is accessible to assessors but protected from unauthorized modification. Assign key custodian roles to named individuals and document the transfer procedure for when those individuals leave the program.

Test revocation checking across domain boundaries during integration testing. Document the test procedure, the results, and the behavior when the revocation service is unreachable. If the CDS fails open on revocation failure, document the risk acceptance. If it fails closed, document the operational impact and the recovery procedure. Do not leave this to the accreditation assessment to discover.

Establish a configuration management entry for every certificate used in the CDS environment, including device certificates, administrator certificates, and CA certificates. Each entry should include the expiration date, the renewal lead time, the renewal procedure, and the assigned owner. Set notification triggers that fire at least 90 days before expiration to allow time for coordination across domain security teams.

Pre-coordinate the emergency revocation procedure with both domain security teams before the system reaches operational status. Walk through the procedure in a tabletop exercise that includes the personnel who would actually execute it. Identify gaps in the procedure, update it based on the exercise findings, and document that the exercise occurred. Repeat the exercise annually or when key personnel change.

Plan for sustainment from the beginning. Identify who will own each crypto control during the operational phase, what training they need, and what documentation they will rely on. The sustainment team should receive a formal transition briefing that covers the key hierarchy, the HSM configuration, the custodian assignments, the rotation schedules, and the emergency procedures. That briefing should be documented and stored with the system documentation package.

Align the crypto control set to the actual key management architecture during RMF control selection. Review the selected controls against the key hierarchy design, the HSM configuration, the credential isolation model, and the revocation architecture to identify gaps. Address those gaps before the assessment, not during it. The ISSO and the system architect should conduct this review together, because neither can do it effectively alone.