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
- Remove the `hsm` section from the Hydra configuration if you do not actually need an HSM.
- Use a Hydra build compiled with HSM support (the build variant with the HSM build tag / cgo enabled and PKCS#11 available).
- Install the PKCS#11 vendor library and required OS packages on the host, then run the HSM-capable binary.
- 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
- Match the binary flavor to the config: HSM config only on HSM-enabled builds
- Smoke-test HSM connectivity in CI before deploying
- Remove the hsm config section on platforms/builds without PKCS#11
- Document which release artifacts include HSM support
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
- issuer URL must be set unless development mode is enabled
- global secret is not configured
- global secret is too short
- The DSN connection string looks like a SQLite connection, bu
- unsupported DSN type
AI-assisted analysis of ory/hydra@4174065ffb (2026-09-03).
Data as JSON: /api/errors/c4b0a7953ac13dad.
Report an issue: GitHub.