Cryptographic deprecation happens at the level applications actually implement: protocol identifiers, library APIs, configuration values, and negotiated behavior. A September 25 IETF Internet-Draft proposes deprecating the JOSE algorithms “none” and “RSA1_5”. The draft cites known security weaknesses and would also strengthen the review criteria for future algorithm registrations.
The document is a work in progress, not a published standard or immediate universal ban. It may change before approval. Even so, it offers a practical inventory lesson: searching for the word “RSA” or counting keys will not show where a vulnerable JSON Web Encryption mode or unsigned JSON Web Signature behavior remains possible.
Protocol identifiers are operational facts
JOSE is used across tokens, APIs, identity systems, gateways, software libraries, and partner integrations. Its algorithm identifiers tell implementations how a message is protected. “none” represents an unsecured JWS, while RSA1_5 identifies RSA PKCS #1 v1.5 key encryption for JWE. The risk depends on how software accepts, produces, validates, or rejects those identifiers.
A cryptographic inventory should therefore record protocol-level names alongside underlying primitives. Useful fields include:
- application, service, library, version, and accountable owner;
- JOSE function—signing, verification, encryption, or decryption;
- algorithms allowed, configured, produced, and actually observed;
- key type, origin, custody, and rotation relationship;
- issuer, consumer, gateway, and partner dependencies;
- fallback and error behavior for unexpected identifiers;
- evidence source, collection date, and observation coverage; and
- target policy, exception, remediation plan, and closure proof.
This is more precise than a generic record saying an application “uses RSA” or “uses JWT.”
Capability, configuration, and use are different
A library can contain code for a deprecated algorithm without an application enabling it. An application can allow an algorithm in configuration without seeing it in production. Conversely, an undocumented partner or legacy client may still send it even after the primary configuration changes.
Teams should preserve all three facts. Software composition and CBOM evidence can identify capable components. Configuration review can show intended policy. Runtime observation and targeted tests can show actual traffic and rejection behavior. None of these alone proves the complete state.
This distinction also prevents unnecessary disruption. Finding a dependency in a package does not automatically mean a vulnerable path is reachable, but it does create a question that needs evidence.
Deprecation is a compatibility project
Removing an algorithm from one service may break token issuers, consumers, mobile clients, integration partners, test fixtures, or recovery processes. That does not justify leaving unsafe behavior enabled indefinitely. It means the change needs an owned compatibility map and an intentional sequence.
A migration unit might include an identity provider, API gateway, several relying services, a client population, and the key-management workflow connecting them. The owner can then define a replacement state, test every participant, monitor rejected messages, and set an exception expiration date for populations that cannot move immediately.
Procurement and supplier reviews should ask whether insecure identifiers are disabled by default, whether they can be fully removed from policy, how unexpected algorithms are handled, and which telemetry proves attempted or successful use.
Registry policy is part of crypto agility
The draft does more than address two identifiers. It proposes baseline security requirements for experts reviewing future JOSE algorithm registrations. Registry decisions shape the choices that libraries and products expose, but organizations still need their own lifecycle process.
Crypto agility is not an unlimited algorithm menu. It is the ability to identify dependencies, evaluate a change, coordinate affected parties, move to an approved target, and prove the resulting state. A registry update should be an input to that loop, triggering impact analysis rather than an emergency search through scattered configuration files.
What organizations should do next
First, locate JOSE implementations through code dependencies, API gateways, identity platforms, configuration repositories, and authorized observation. Search for exact identifiers as well as library features.
Second, classify each finding as supported capability, allowed configuration, observed production use, or unknown. Keep the evidence and its date.
Third, map producers and consumers before changing policy. Include external partners and older client populations.
Fourth, test rejection behavior. A secure configuration should fail safely when it receives an unexpected or deprecated algorithm rather than silently falling back.
Finally, attach deprecation decisions to owners, target dates, exceptions, and re-observation. Completion means the relevant populations use the approved state and deprecated behavior is rejected as intended.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams connect cryptographic identifiers and implementations to assets, owners, policy, remediation, exceptions, and evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory and CBOM and compliance resources.
Where uncertainty remains
This source is an Internet-Draft and may be revised, replaced, or expire. Its proposed deprecation does not establish that every implementation is exposed or that every migration should follow the same schedule. The durable lesson is that algorithm lifecycle management needs protocol-specific inventory evidence. Without it, teams cannot distinguish dormant capability from configured or observed risk.
Source
- JOSE: Deprecate “none” and “RSA1_5” (draft-ietf-jose-deprecate-none-rsa15-06), Internet Engineering Task Force, September 25, 2026.