ory/hydra · critical · ErrOpSysNotSupported

Hardware Security Module is not supported on this platform.

Error message

Hardware Security Module is not supported on this platform.

What it means

This is Hydra's fallback KeyManager (`hsm/manager_nohsm.go`) error. This build of the binary was compiled without Hardware Security Module (HSM/PKCS#11) support, so every key-manager operation (GenerateAndPersistKeySet, GetKey, GetKeySet, DeleteKey, DeleteKeySet, AddKey) returns ErrOpSysNotSupported, and NewContext fatals at startup. It indicates a binary/platform mismatch: HSM configuration was requested but the nohsm stub is linked in.

Source

Thrown at hsm/manager_nohsm.go:32

	"github.com/pkg/errors"

	"github.com/ory/hydra/v2/jwk"

	"github.com/go-jose/go-jose/v3"
)

type Context interface {
}

type KeyManager struct {
	jwk.Manager
	sync.RWMutex
	Context
	KeySetPrefix string
}

var ErrOpSysNotSupported = errors.New("Hardware Security Module is not supported on this platform.")

func NewContext(c *config.DefaultProvider, l *logrusx.Logger) Context {
	l.Fatalf("Hardware Security Module is not supported on this platform.")
	return nil
}

func NewKeyManager(hsm Context, config *config.DefaultProvider) *KeyManager {
	return nil
}

func (m *KeyManager) GenerateAndPersistKeySet(_ context.Context, set, kid, alg, use string) (*jose.JSONWebKeySet, error) {
	return nil, errors.WithStack(ErrOpSysNotSupported)
}

func (m *KeyManager) GetKey(_ context.Context, set, kid string) (*jose.JSONWebKeySet, error) {
	return nil, errors.WithStack(ErrOpSysNotSupported)
}

View on GitHub (pinned to 4174065ffb)

Solutions

  1. Remove the `hsm` section from the Hydra configuration if you do not actually need an HSM.
  2. Use a Hydra build compiled with HSM support (the build variant with the HSM build tag / cgo enabled and PKCS#11 available).
  3. Install the PKCS#11 vendor library and required OS packages on the host, then run the HSM-capable binary.
  4. If self-building, build with the HSM enabled tag and verify the resulting binary connects to the HSM before deploying.

Example fix

# before: vanilla image with HSM config
image: oryd/hydra:latest
hsm:
  library: /usr/lib/softhsm.so
# after: either drop hsm config or use HSM-enabled build
image: oryd/hydra:latest-hsm   # or custom build with HSM tag
hsm:
  library: /usr/lib/softhsm.so
Defensive patterns

Strategy: fallback

Validate before calling

// verify at boot whether HSM is actually usable in this build/binary
if hsmConfigured && !buildHasHSM() {
    log.Fatal("hsm configured but this binary lacks HSM support; use the HSM build or remove hsm config")
}

Prevention

When it happens

Trigger: Running a Hydra binary built without the `hsm` build tag (or the standard release) while `hsm` configuration is present in the config; any call to the KeyManager interface in such a build; NewContext is invoked during setup and logs a fatal error.

Common situations: Operators set `hsm:` config copied from an HSM-enabled deployment but run the vanilla Docker image; downloading the default release binary instead of the HSM/cgo build; CI images lacking PKCS#11 libraries; platform where HSM support simply is not compiled.

Related errors


AI-assisted analysis of ory/hydra@4174065ffb (2026-09-03). Data as JSON: /api/errors/c4b0a7953ac13dad. Report an issue: GitHub.