TL;DR: Federal agencies required FBCA cross-certified certificates for non-federal organizations exchanging EHRs through Directed Exchange, and DigiCert said three out of four accredited HISPs already had full access through its partnership. The policy shows how interoperability now depends on certificate lifecycle governance, not just transport security, especially where identity assurance must span healthcare boundaries.
At a glance
What this is: DigiCert reports that FBCA cross-signing is now required for certain Directed Exchange use cases, tying healthcare interoperability to certificate lifecycle governance and accredited trust paths.
Why it matters: IAM and certificate teams need to treat cross-certification, issuance, and revocation as governance controls because interoperability now depends on trust that spans organisational and federal boundaries.
Context
FBCA cross-signing is a certificate trust model, not a transport feature. In this article, the issue is how healthcare organisations prove identity and preserve trust when exchanging electronic health records with federal agencies through Directed Exchange, where certificate provenance and lifecycle management become part of the access decision itself.
The governance gap is straightforward: a certificate can be technically valid yet still fail the interoperability requirement if it is not issued through an accredited and cross-certified path. For IAM, PKI, and certificate lifecycle owners, that turns trust federation into an operational control plane rather than a background dependency.
Key questions
Q: How should organisations govern certificates used for cross-domain healthcare exchange?
A: They should treat certificates as governed identities, not just technical credentials. That means assigning ownership, tracking expiry and renewal, validating trust chains against the relying party's rules, and revoking access when partner status changes. In regulated exchange, lifecycle failures become access failures.
Q: Why can a valid certificate still fail in federated exchange?
A: A certificate can be cryptographically valid and still fail if its trust chain is not recognised by the relying environment. Federated exchange adds policy, accreditation, and cross-certification requirements on top of certificate validity. Practitioners need to manage the trust path, not just the expiry date.
Q: What are the biggest certificate lifecycle mistakes in interoperability programmes?
A: The most common mistakes are treating cross-certification as a one-time setup, failing to track which certificates are approved for which partner, and leaving revocation ownership unclear. Those gaps create interoperability failures even when issuance and transport are working correctly.
Q: How do organisations know if certificate governance is ready for external exchange?
A: Readiness shows up when the organisation can answer three questions without ambiguity: which trust framework applies, who owns the certificate lifecycle, and how revocation or renewal affects each exchange partner. If any of those answers are unclear, the programme is not ready for federated trust.
Technical breakdown
Why cross-certified certificates matter for Directed Exchange
Federal cross-signing creates a trust bridge between organisations that do not share a single issuing hierarchy. In practice, that means the relying party can validate the certificate chain back to an authority accepted by the federal trust framework, rather than relying on local trust alone. For certificate lifecycle governance, the critical issue is not simply whether a certificate exists, but whether it was issued, chained, and managed within an approved trust boundary that supports the exchange scenario.
Practical implication: Validate the certificate path and trust anchor before onboarding any exchange flow that depends on federal interoperability.
Certificate lifecycle governance as an interoperability control
Lifecycle governance covers issuance, renewal, revocation, and retirement. In a cross-certified model, each step affects whether a certificate remains acceptable to both sides of an exchange relationship, especially when multiple accrediting bodies and relying parties are involved. That makes lifecycle control a compliance and continuity problem, not just a PKI hygiene task. If the certificate estate is poorly governed, interoperability can fail even when the application, transport, and user workflow are all functioning.
Practical implication: Tie certificate inventory and revocation workflows to the specific trust requirements of each exchange partner.
Why accreditation and trust bundles change the operating model
The article highlights accredited HISPs, DirectTrust, and FBCA cross-certification because interoperability depends on more than technical validity checks. Accreditation tells the relying environment that the issuing path, registration process, and trust handling meet a recognised standard. That shifts certificate management from a single-team PKI activity to a shared governance model spanning certificate authorities, registration authorities, and the exchange community.
Practical implication: Map every certificate-dependent exchange to the accrediting and trust frameworks that govern it, then keep ownership explicit across teams.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cross-signing turns certificate lifecycle into an access governance problem. The article is not really about transport security, it is about who is allowed to participate in a trusted exchange relationship. Once federal interoperability depends on FBCA cross-certified credentials, the certificate lifecycle becomes part of the trust decision, not an after-the-fact administrative function. The practical conclusion is that PKI teams and IAM teams must govern certificates as active identity assets.
FBCA cross-signing exposes the limits of local-only trust models. A certificate that is technically sound inside one environment may still be unusable for a federated exchange if its trust path is not recognised by the other side. That is a governance constraint, not a cryptographic one. The implication is that organisations need lifecycle policies that understand external relying parties, not just internal issuance rules.
Accreditation is the control plane for federated certificate trust. DirectTrust accreditation, HISP relationships, and FBCA cross-certification together define whether a certificate can participate in the exchange community. That means ownership spans CA operations, registration processes, and policy enforcement across organisations. Practitioners should treat accreditation status as a live dependency in certificate governance, not a one-time procurement fact.
Identity assurance now extends beyond the user to the certificate path itself. The article shows that patient record protection depends on both the entity being identified and the trust chain used to identify it. This broadens IAM thinking for healthcare: assurance is no longer only about who authenticates, but also about whether the credential used in the exchange is anchored to an acceptable trust framework. The practitioner takeaway is to align certificate governance with assurance requirements, not just issuance workflows.
Certificate lifecycle management is the named concept that explains the policy shift. FBCA cross-signing works only when issuance, renewal, revocation, and partner trust are governed as one lifecycle. That concept matters because interoperability now breaks when any part of that lifecycle falls outside the approved trust path. Practitioners should manage certificates as federated identity assets with explicit trust provenance.
What this signals
Certificate lifecycle governance now functions as interoperability governance. Healthcare identity teams cannot separate trust from operations when external exchange depends on an approved certificate path. The right operating model is to manage certificate provenance, renewal, and revocation as part of the access decision, not as back-office PKI maintenance.
The practical shift is from local certificate validity to federated trust assurance. That means healthcare IAM and PKI teams should maintain a live map of which exchange paths rely on cross-certified credentials, who owns them, and what breaks when partner trust changes.
For practitioners
- Map exchange dependencies to trust anchors Document every Directed Exchange use case that depends on federal interoperability, then verify which trust anchor and accreditation path each one requires.
- Inventory cross-certified certificate estates Separate certificates that are merely valid from those that are FBCA cross-certified and approved for the specific exchange relationship.
- Align revocation workflows with partner trust Ensure revocation, renewal, and replacement processes are coordinated with the relying organisations that depend on the certificate path.
- Assign clear ownership across CA, RA, and HISP teams Record who owns issuance, accreditation status, lifecycle operations, and partner onboarding for each exchange certificate.
- Test interoperability before relying on production exchange Validate that the certificate chain, trust bundle, and accreditation status all satisfy the target exchange requirement before go-live.
Key takeaways
- Directed Exchange requirements turn certificate trust into a governance issue, not just a technical PKI issue.
- Cross-signing only helps when issuance, accreditation, and revocation stay aligned with the relying exchange community.
- IAM and certificate teams should manage certificates as federated identity assets with explicit trust provenance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0, CSA Cloud Controls Matrix and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate issuance, renewal, and revocation are central to the article's trust model. |
| Recommendation — Apply IA-5 to govern certificate issuance, renewal, rotation, and revocation across exchange partners. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cross-certified certificates determine whether exchange access is authorised across organisations. |
| Recommendation — Map certificate trust requirements to PR.AA-05 and verify authorisation before exchange onboarding. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is about federated identity trust for healthcare exchange in cloud-adjacent environments. |
| Recommendation — Use IAM controls to track certificate owners, approval paths, and cross-organisation trust acceptance. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article depends on managed certificate and key lifecycle governance for interoperability. |
| Recommendation — Govern certificate and key lifecycles through issuance, distribution, renewal, and destruction policies. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Cross-organisational certificates must be revoked when exchange relationships or trust status change. |
| Recommendation — Revoke certificates promptly when exchange relationships end or trust status changes. | ||
Key terms
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Cross-Certification: Cross-certification is a trust arrangement that lets one certificate authority's credentials be accepted under another authority's rules. In practice, it bridges separate trust domains so organisations can exchange data or services while still proving identity to the relying party's required standard.
- Directed Exchange: A standards-based healthcare exchange pattern for securely sending electronic health records between trusted parties. The exchange depends on identity assurance, accredited trust paths, and certificate governance so that records can move across organisations without weakening privacy or authenticity controls.
- Accredited Trust Path: The approved chain of authorities, policies, and registrations that makes a credential acceptable for a specific exchange use case. In practice, it tells the relying organisation which certificates count as trustworthy and which do not, even when the underlying cryptography is valid.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org