Stronghold mechanisms help meet typical information security requirements. The tables below map each requirement group to a mechanism, the edition that provides it, and the page where you configure it. Use them when you prepare a threat model, a technical specification, or a document package for certification of your information system.
Compliance of an information system with regulatory requirements is determined by the system as a whole: its architecture, organizational measures, and the configuration of all components. The presence of a mechanism in Stronghold does not mean that a requirement is met automatically.
Certification and registries
| Document | Details | Edition |
|---|---|---|
| FSTEC of Russia certificate | Certificate No. 5038 dated February 10, 2026, for Deckhouse Stronghold software (version 1.16). Conformity with FSTEC of Russia Order No. 76, trust level 4 | Stronghold CSE |
| Unified Register of Russian Software | Registry entry No. 22339 dated April 24, 2024 | — |
The certificate and registry details are also listed in the release notes and on the Editions page.
Mapping requirements to mechanisms
| Requirement group | Stronghold mechanism | Edition | Where to configure |
|---|---|---|---|
| Identification and authentication of users and services | LDAP, OIDC, JWT, Kubernetes, AppRole, userpass, token, and WebAuthn auth methods | All | Auth methods |
| Authentication via an external SAML 2.0 IdP | Stronghold EE | SAML | |
| Multi-factor authentication (TOTP, Multifactor) | All | MFA | |
Account lockout after failed login attempts (user_lockout) | All | user_lockout section | |
| A single user entity across multiple login methods | All | Identity | |
| Access control | Deny-by-default ACL policies, explicit deny with the highest priority | All | Policies |
| Tokens with a limited lifetime and revocation | All | Tokens | |
| Isolation of configuration and secrets between teams, Namespace API lock | Stronghold EE | Namespaces | |
| Granting administrator rights by IdP groups in Deckhouse Platform (DP) | All | Access management | |
| Security event logging | Audit log of all API requests and responses (file, syslog, socket devices) | All | Audit |
| Hashing of sensitive data in the log (HMAC-SHA256) | All | Audit log record schema | |
| Record filtering and field exclusion | All | Filtering, field exclusion | |
| Cryptographic protection of data at rest | AES-256-GCM cryptographic barrier | All | Cryptographic algorithms |
| Root key protection in an HSM (PKCS #11) or Yandex Cloud KMS | HSM: Stronghold EE | HSM, Yandex Cloud KMS | |
| Additional encryption of critical data (seal wrap) | Stronghold EE | Double encryption | |
| Unseal key splitting (Shamir), key rotation (rekey) | All | Seal and unseal | |
| Cryptographic protection of data in transit | TLS 1.2/1.3, client certificate verification (mTLS) | All | Cryptographic algorithms, listener section |
TLS 1.3 with GOST encryption, GOST algorithms in PKI and Transit | Stronghold EE | GOST algorithms | |
| Key and certificate management | Certificate issuance, encryption and signing as a service, managed keys in external systems | PKI, Transit: all; Managed Keys: Stronghold EE | PKI, Transit, Managed Keys |
| Secret lifecycle management | Dynamic credentials with a limited lifetime, rotation, and revocation | All | Leases, database secrets engines |
| Complexity policies for generated passwords | All | Password policies | |
| Integrity | Data integrity control by the AES-GCM barrier | All | Cryptographic algorithms |
| SHA256 verification of external plugin binaries | All | Plugins | |
| Configuration changes only through a quorum of Git commit signatures | Stronghold EE | GitOps secrets engine | |
| Snapshot consistency check | All | Inspecting a snapshot | |
| Backup and recovery | Manual Raft storage snapshots | All | Saving a snapshot, restoring |
| Scheduled snapshots to local or S3-compatible storage | Stronghold EE | Automated snapshots | |
| Availability and fault tolerance | HA cluster on integrated Raft | All | Installation |
| Performance standby, cross-cluster Performance and DR replication | Stronghold EE | Replication | |
| Recovery after losing Raft quorum | All | Standalone, DP |
Russian regulatory requirements
The table lists regulations that are usually taken into account when deploying secret management systems in Russia. Applicability and specific measures are determined separately for your system.
| Regulation | How Stronghold helps meet the requirements |
|---|---|
| FSTEC of Russia Order No. 76 (information security requirements establishing trust levels) | Stronghold CSE is certified for trust level 4 (certificate No. 5038) |
| Federal Law No. 152-FZ “On Personal Data” and personal data protection requirements | |
| Federal Law No. 187-FZ “On the Security of Critical Information Infrastructure” | |
| Requirements for state information systems (FSTEC of Russia Order No. 17) | |
| Use of Russian software | Entry No. 22339 in the Unified Register of Russian Software |
| GOST cryptographic protection | Stronghold EE supports GOST algorithms in TLS, PKI, and Transit. Stronghold CSE does not support GOST algorithms for PKI/Transit. For the edition comparison, refer to Editions. |
Security settings
To reduce the risk of compromise, apply the following Stronghold settings:
- Enable at least two audit devices and forward logs to a SIEM.
- Set the minimum TLS version to
tls12. - Store unseal and recovery keys separately with several responsible persons.
- Use short token lifetimes and dynamic secrets instead of static ones.
- Configure automated snapshots stored outside the protected cluster and test recovery regularly.
- Do not use the root token for day-to-day work: perform administration under accounts with assigned policies.