RSA

Expanded Definition

RSA is a public key cryptographic algorithm used for digital signatures and, in some systems, encryption. In NHI and IAM environments, its most common role is signing tokens, certificates, and trust assertions where compatibility matters more than minimal key size or fastest performance. As a mature algorithm, RSA remains widely supported by identity providers, PKI toolchains, and hardware security modules, but its operational value depends on correct key management, certificate lifecycle control, and consistent validation policy.

In practice, RSA is not the same thing as authentication itself. It is a cryptographic primitive that underpins how an AI agent, service account, workload, or platform proves possession of a private key. Definitions vary across vendors when discussing algorithm choice in federated identity, but the security outcome is consistent: if the private key is exposed, the trust boundary collapses. The NIST Cybersecurity Framework 2.0 helps anchor this operationally by tying identity assurance to governance and protective controls, while NHI programmes must treat RSA keys as secrets with explicit lifecycle ownership. The most common misapplication is assuming RSA is “secure by default,” which occurs when teams reuse long-lived keys without rotation, monitoring, or certificate expiry enforcement.

Examples and Use Cases

Implementing RSA rigorously often introduces certificate and key-management overhead, requiring organisations to weigh broad interoperability against rotation discipline and performance constraints.

• Signing JWTs for service-to-service authentication where older runtimes or third-party consumers require RSA compatibility.
• Issuing X.509 certificates for workloads and agents that must be validated across heterogeneous infrastructure, as discussed in the Ultimate Guide to NHIs.
• Protecting trust anchors in enterprise PKI, where RSA remains supported by many identity systems even as teams evaluate elliptic curve alternatives.
• Using RSA in federated identity integrations that need stable interoperability with external partners and legacy validation libraries.
• Applying RSA-based signing to non-human credentials while enforcing the control expectations outlined in NIST Cybersecurity Framework 2.0.

RSA is especially relevant when a workload must authenticate across older vendors, but it should still be paired with key rotation, certificate expiry tracking, and restricted private-key access. For NHI operators, the cryptography is only as trustworthy as the controls around issuance and revocation. NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which makes any long-lived RSA credential a governance issue, not just a technical one.

Why It Matters in NHI Security

RSA matters because many NHI trust chains still depend on it, and that means compromise of a private key can impersonate a workload, service, or agent at scale. When RSA keys are embedded in code, stored outside managed secret systems, or left active after service decommissioning, attackers gain durable access that is hard to spot and even harder to unwind. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and this is exactly where weak RSA key hygiene becomes operationally dangerous. The same guide also shows that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, reinforcing that cryptographic strength alone does not prevent identity abuse.

RSA therefore sits at the intersection of algorithm selection, secret governance, and incident response. Security teams should validate where RSA is truly required, reduce key lifetime, and ensure private keys are covered by rotation, access review, and revocation processes. If the organisation still relies on RSA for agent signing or workload authentication, that reliance must be visible to governance owners, not hidden inside deployment templates. Organisations typically encounter the full impact of RSA mismanagement only after a key leak, certificate misuse, or failed offboarding event, at which point RSA governance becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should IAM teams evaluate RSA alternatives for enterprise use?
• What breaks when an HSM’s boot trust still depends on RSA or ECC?
• How should security teams migrate identity systems from RSA to modern signature algorithms?
• When does RSA create more operational risk than it reduces?