---
layout: docs
page_title: Upgrading to Vault 1.10.x - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 1.10.x. Please read it carefully.
---

# Overview

This page contains the list of deprecations and important or breaking changes
for Vault 1.10.x compared to 1.9. Please read it carefully.

## SSH Secrets Engine

The new default value of `algorithm_signer` for SSH CA roles has been changed
to `rsa-sha2-256` from `ssh-rsa`. Existing roles will be migrated to
explicitly specify the `algorithm_signer=ssh-rsa` for RSA keys if they used
the implicit (empty) default, but newly created roles will use the new default
value (preferring a literal `default` which presently uses `rsa-sha2-256`).

### Etcd v2 API no longer supported

Support for the Etcd v2 API is removed in Vault 1.10. The Etcd v2 API
was deprecated with the release of [Etcd v3.5](https://etcd.io/blog/2021/announcing-etcd-3.5/),
and will be decommissioned in a forthcoming Etcd release.

Users of the `etcd` storage backend with the etcdv2 API that are
upgrading to Vault 1.10 should [migrate](/docs/commands/operator/migrate)
Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1.10.
All storage migrations should have
[backups](/docs/concepts/storage#backing-up-vault-s-persisted-data)
taken prior to migration.

### OTP Generation Process

Customers passing in OTPs during the the process of generating root tokens must modify
the OTP generation to include an additional 2 characters before upgrading so that the
OTP can be xor-ed with the encoded root token. This change was implemented as a result
of the change in the prefix from hvs. to s. for service tokens.

## Token Format Change

Token prefixes were updated to be more easily identifiable.

- Service tokens previously started with s. now start with hvs.
- Batch tokens previously started with b. now start with hvb.
- Recovery tokens previously started with r. now start with hvr.

Additionally, non-root service tokens are now longer than before. Previously, service tokens
were 26 characters; they now have a minimum of 95 characters. However, existing tokens will
still work.

Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details.

## OIDC Provider Built-in Resources

In Vault 1.9, the [OIDC identity provider](/docs/secrets/identity/oidc-provider) feature
was released as a tech preview. In Vault 1.10, built-in resources were introduced to the
OIDC provider system to reduce configuration steps and enhance usability.

The following built-in resources are included in each Vault namespace starting with Vault
1.10:

 - A "default" OIDC provider that's usable by all client applications
 - A "default" key for signing and verification of ID tokens
 - An "allow_all" assignment which authorizes all Vault entities to authenticate via a
   client application

If you created an [OIDC provider](/api-docs/secret/identity/oidc-provider#create-or-update-a-provider)
with the name "default", [key](/api-docs/secret/identity/tokens#create-a-named-key) with the
name "default", or [assignment](/api-docs/secret/identity/oidc-provider#create-or-update-an-assignment)
with the name "allow_all" using the Vault 1.9 tech preview, the installation of these built-in
resources will be skipped. We _strongly_ recommend that you delete any resources that have
naming collisions before upgrading to Vault 1.10. Failing to delete resources with naming
collisions could result unexpected default behavior. Additionally, we recommend reading the
corresponding details in the OIDC provider [concepts](/docs/concepts/oidc-provider) document
to understand how the built-in resources are used in the system.
