Security standard SS-007: Use of Cryptography
Updated 6 June 2025
Chief Security Office
Date: 25/03/2025
Version 2.1
This Use of Cryptography Security Standard is part of a suite of standards, designed to promote consistency across the Department for Work and Pensions (DWP), and supplier base with regards to the implementation and management of security controls. For the purposes of this standard, the term DWP and Authority are used interchangeably.
Technical security standards form part of the DWP Digital Blueprint which is a living body of security principles, architectural patterns, code of practice, practices and radars, that aim to support Product Delivery Units (PDUs) and suppliers in delivering the DWP and HMG Digital Strategy. Security standards and policies considered appropriate for public viewing are published here:
Government Publications Security Policies and Standards
Technical security standards cross-refer to each other where needed, so can be confidently used together. They contain both mandatory and advisory elements, described in consistent language (see table below).
(Important note for screen reader users.) Paragraphs that contain a ‘must’ statement, and therefore denote a mandatory requirement, will contain the following statement after the heading:
(Important) this paragraph contains ‘must’ activities.
1. Table 1 – Terms
Term | Intention |
---|---|
must | denotes a requirement: a mandatory element. |
should | should denotes a recommendation: an advisory element. |
may | denotes approval. |
might | denotes a possibility. |
can | denotes both capability and possibility. |
is/are | is/are denotes a description. |
2. Revision history
Version | Description | Date |
---|---|---|
1.0 | First published version | 04/2017 |
2.0 | Full update in line with current best practices and standards, recorded NIST references and made changes to grammar. Introduction and Scope updated for Mandatory ‘must’ statements and introduced Crypto manual. FIPS 140 and CPA assurance requirements updated throughout. 11.1 Reworded. 11.1.4 - refined requirement to implement in accordance with Crypto manual that supports assurance TOE. 11.2.1 and 11.4.1 - grammar refresh. 11.5.1 - PKCS minimum version updated. 11.6.3 subsumed into 11.6.2. 11.7.2 Introduced TPM. 11.8.1 updated Salt value | 07/12/2022 |
2.1 | All NIST references reviewed and updated to reflect NIST 2.0 All security measures reviewed in line with risk and threat assessments. Approval history - Review period changed to up to 2 years. Intro – Mitigating factors & compensating controls; Quantum resistant cryptography; defence in depth. References to NCSC CPA removed as it no longer supports encryption products. 11.1.2 Patching cryptographic systems. 11.1.7 Monitoring cryptographic systems. 11.2.8 Quantum resistant algorithms. 11.3.1 Elliptic Curve Cryptography. 11.3.2 Must. 11.6.4 Logon and privileged functions. 11.8.1 Cryptographic salting. Internal Refs – version number removed from DWP Approved Crypto Algorithms document. External refs & Glossary - Quantum resistant cryptography | 25/03/2025 |
3. Approval history
Version | Role | Date |
---|---|---|
1.0 | Chief Security Officer | 02/04/2017 |
2.0 | Chief Security Officer | 07/12/2022 |
2.1 | Chief Security Officer | 25/03/2025 |
This document is continually reviewed to ensure it is updated in line with risk, business requirements, and technology changes, and will be updated at least every 2 years - the current published version remains valid until superseded.
4. Compliance
Compliance with this standard will be verified through various methods, including but not limited to;
-
controls tests performed by 1st line teams and by 2nd line activities (e.g. security testing teams)
-
security assurance activities to ensure that Architectural Design and delivery are appropriate and aligned to applicable Authority Security Standards [See Security Assurance Strategy – Ref. D]
-
independent external audit
Results of these will be fed back to the appropriate Authority Risk and System Owners.
5. Exceptions Process
(Important) this paragraph contains ‘must’ activities.
In this document the term “must” is used in bold letters to indicate a mandatory security measure. Any exceptions to the application of this standard, or where specific security measures cannot be adhered to, must be presented to the Authority. This must be carried out prior to deployment and managed through the design caveats or exception process.
Such exception requests will invoke the Risk Management process to clarify the potential impact of any deviation to the configuration detailed in this standard.
Exceptions to the standard must be maintained on a risk register for accountability, traceability, and security governance reporting to senior management.
6. Audience
This document is intended for, but not necessarily limited to, technical architects, engineers, developers, security teams, project teams, including suppliers engaged in the design, development, implementation and operation of systems, services and applications. It must be applied in the design, assurance, and audit of cryptographic controls deployed across the Authority and supplier base where applicable.
7. Accessibility statement
(Important) this paragraph contains ‘must’ activities.
Users of this standard must consider accessibility design requirements as appropriate. Further information on accessibility standards can be found in Appendix F.
8. Introduction
(Important) this paragraph contains ‘must’ activities.
This standard defines a set of minimum-security measures that must be met when implementing cryptographic controls for the purposes of mitigating risks, or to comply with legal and regulatory requirements or both. When considering risk, an assessment must include consideration of mitigating factors and compensating controls.
Cryptographic controls must be implemented whenever it is necessary to protect the confidentiality and integrity of electronic information in transit or at rest from threats facing the Authority. Threats can be physical or logical in nature such as media containing sensitive data being stolen, or hackers sniffing data packets across the network. Cryptographic controls can also be used to authenticate the identities of both the sender and recipient to one another and protect against repudiation.
Below are some examples of when cryptographic controls must be used:
-
Sending sensitive data over an untrusted network e.g., between two endpoints over the internet
-
Storing sensitive data in a multi-tenanted cloud hosted environment e.g., passwords, personal citizen information
-
Connecting remote workers from home to access the Authority’s network
-
Protecting citizen data at rest e.g., in databases or object stores
-
To comply with legal or regulatory requirements
One of the biggest challenges that cryptography faces today is the future threat from substantially more powerful quantum computers. Quantum computing leverages the properties of quantum physics to perform operations that are impossible or impractical for classical computers, and thus has the potential to impact asymmetric, and to a lesser extent symmetric cryptographic operations. To address this challenge, post-quantum cryptography (PQC) algorithms are being developed that are resistant to quantum attacks. See ‘NIST Post-Quantum Cryptography’ and ‘NCSC: Post-Quantum Cryptography – what comes next ?’ [External References].
See the DWP Approved Cryptographic Algorithms document [Ref. B] for approved algorithms.
It should also be noted that weak passwords, social engineering attacks, and accidental data exposure are common pitfalls in maintaining secure encrypted systems, so a ‘defence-in-depth’ approach must be followed to protect Authority data.
As this standard only provides minimum measures, they should be exceeded as appropriate depending on the threats and risks that need to be addressed, the sensitivity of the data, and in keeping with latest security enhancements.
The security measures are derived from industry best practice i.e., guidance published by NIST, CIS and OWASP (see Appendix C for full list external references) and support the implementation of appropriate security controls as selected by DWP or our third-party providers, such as the CIS Critical Security Controls set. [see External References]
Every effort has been made to ensure the security measures are vendor and technology agnostic as far as possible; this is to ensure greater applicability of the standard regardless of the technologies used. The security measures may be implemented in different ways, depending on the technology choices and business requirements in question.
The aim of this standard is to:
-
enable technical teams to work towards a set of minimum-security measures which are based on industry best practice
-
ensure cryptographic controls are designed, developed, and deployed consistently respecting the cryptographic manual on which validation was awarded
-
ensure cryptographic controls are configured to only use Authority approved cryptographic algorithms as defined in DWP Approved Cryptographic Algorithm document [Ref. B]
-
enforce the use of independently assured cryptographic products where needed
Technical security standards ultimately support the achievement of security outcomes sought by the Authority. They set the expectations for what needs to be done to achieve them and why, and provide an objective, measurable statement of the Authority’s existing security posture in a number of important areas. The outcomes are based on the official NIST sub-categories where possible to ensure close alignment with the NIST Cyber Security Framework (CSF), and are enabled by the implementation of controls from the CIS Critical Security Controls set. [see External References]. Those relevant to the subject of each standard can be found in Appendix A of every technical security standard.
9. Purpose
The purpose of this standard is to ensure systems and services utilising cryptography to encrypt Authority data are designed, configured, deployed, and managed consistently to protect against typical threats at the OFFICIAL tier.
This standard also serves to provide a baseline in which assurance and compliance activities can be carried out, so that the Authority can be assured that security obligations are being met or exceeded.
10. Scope
(Important) this paragraph contains ‘must’ activities.
This standard must be applied whenever it is determined that cryptographic controls are required following a security risk assessment process or to satisfy legal and regulatory requirements. Therefore, all the Authority’s ICT systems, networks, and end user devices including portable storage devices are in scope of this standard.
There are however certain measures regarding the use of cryptography in the cloud deliberately excluded from this standard, as this is covered in SS-023 – Cloud Computing Security Standard [Ref. C]. As such, this standard must be read in conjunction with SS-023.
It should also be noted that while key management is a fundamental aspect of ensuring the security of information protected by cryptography, this area is outside of the scope of this standard and is covered elsewhere in SS-002 PKI and Key Management Security Standard [Ref. D].
Where FIPS 140 is referenced, the dash numbers are not included e.g. FIPS 140-2. The reason for this is that these represent versions of the standard that are valid for a period of time for certification to be issued against. These certificates have a defined lifespan, so that older versions of the FIPS 140 standard expire over time. Hence newer versions of the FIPS standard are automatically covered.
The security measures must be applied to new and existing installations, and adherence to these measures must be included in all contracts for outsourced services where applicable.
Any queries regarding the security measures laid out in this standard must be sent to an assigned DWP Security Architect or Project Team Lead.
11. Minimum Technical Security Measures
(Important) this paragraph contains ‘must’ activities.
The following section defines the minimum security measures that must be implemented to achieve the security outcomes described in Appendix A. For ease of reference, the official NIST sub-category ID is provided against each security measure e.g. PR.PT-3, to indicate which outcome(s) it contributes towards. Refer to Appendix A for full description of outcomes.
11.1. Software and Hardware Requirements
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.1.1 | The Cryptographic software deployed must be selected having an active validation to FIPS 140 and FIPS 197. | PR.DS-01 PR.DS-02 |
11.1.2 | Systems supporting cryptographic operations must be kept up to date in line with SS-033 Security Patching Standard [Ref. E]. | PR.PS-02 |
11.1.3 | Cryptographic hardware deployed must have an active validation against a recognised scheme. FIPS 140 and FIPS 197 meet this standard. | PR.DS-01 PR.DS-02 |
11.1.4 | Cryptographic software / hardware must be deployed, configured, and operated in accordance with the security procedures and cryptographic manual supporting the products’ validation. | PR.DS-01 PR.DS-02 PR.PS-01 PR.PS-02 PR.PS-03 |
11.1.5 | Cryptographic software / hardware must only be used when still under active vendor support or still inside its validation period. | PR.PS-02 PR.PS-03 |
11.1.6 | Where applicable cryptographic operations must be performed on hardware, this requires appropriate validations to be in place; For HSMs, FIPS 140 at level 3 or higher; For TPMs, v2.0 or higher; Where applicable, cryptographic operations must be used in software, this requires appropriate validations to be in place; For software packages, FIPS 140 at level 2 or higher; For software libraries, FIPS 140 at level 1 or higher | PR.DS-01 PR.DS-02 |
11.1.7 | Cryptographic systems must be monitored for anomalies such as unusual patterns or activities that may indicate a potential attack. Anomaly detection mechanisms can help identify and respond to suspicious behaviour promptly. | DE.CM-09 |
11.2. Cryptographic Algorithm Requirements
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.2.1 | Cryptographic algorithms and modes of operation must be selected from the DWP Approved Cryptographic Algorithms document [Ref. B]. Note. Approval by the Authority is indicated by inclusion in the above document. Where multiple algorithms are deployed, the order of preference given by this document must also be technically enforced. | PR.DS-01 PR.DS-02 |
11.2.2 | Approved asymmetric cryptography must be used where the use of symmetric cryptography is inappropriate e.g. weaknesses in implementation, unable to handle certificate exchange or physical key exchange, or for authentication purposes. | PR.DS-01 PR.DS-02 |
11.2.3 | The list of approved cryptographic algorithms must be reviewed at least annually. | PR.PS-02 |
11.2.4 | Approved hashing algorithms must be used as the basis for: Creating message digests; Generating digital signatures; Message Authentication Codes (MACs / HMACs); Pseudorandom Functions (PRFs); Key Derivation Functions (KDFs). See the DWP Approved Cryptographic Algorithms document [Ref. B] for approved algorithms. | PR.DS-01 PR.DS-02 |
11.2.5 | Where information is to be encrypted and authenticated, the Message Authentication Code (MAC) must be computed after encryption (i.e. encrypt-then-MAC). | PR.DS-01 PR.DS-02 |
11.2.6 | Use of Elliptic Curve Cryptography (ECC) curves and key parameters must be selected from those recommended in the latest version of FIPS 186. | PR.DS-01 |
11.2.7 | Use of Diffie Hellman key exchange algorithm must be used in conjunction with the following parameters as appropriate: DH Group 19, DH Group 20, DH Group 21 | PR.DS-01 |
11.2.8 | Wherever possible, quantum-resistant algorithms must be used. Even though quantum computing capabilities may not currently be mature enough to break many forms of encryption in use today, it is known that threat actors are collecting vast quantities of encrypted data to potentially decrypt once quantum computing capabilities become more generally available. See the DWP Approved Cryptographic Algorithms document [Ref. B] for approved algorithms. | PR.DS-01 |
11.3. Generation of Cryptographic Key Material
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.3.1 | Where pseudorandom number generation is required, but not provided as part of vendor software, (including initialisation vectors), this must use cryptographically secure sources of entropy (using Elliptic Curve Cryptography). Acceptable sources are: External modules which have received FIPS 140 certification. Operating system certified sources (e.g. Microsoft CryptoAPI:NG, /dev/random). | PR.DS-01 |
11.3.2 | Virtual Machines (VMs) and operating systems running on Solid State Drives (SSDs) must utilise an assured feed of pseudorandom data from an external entropy feed (as per the section above), as they cannot be relied upon to produce their own, except in the case where an external module described in section 11.3.1 above is deployed. | PR.DS-01 |
11.4. Compression
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.4.1 | Compression of data must be a separate process to the encryption and decryption operations themselves. Compression routines that execute alongside encryption and decryption functions (e.g. TLS compression) must not be used. | PR.DS-01 |
11.5. Message Padding
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.5.1 | Messages to be encrypted by an approved asymmetric algorithm must use PKCS#1 v2.2 minimum. Fallback to earlier version is not allowed. | PR.DS-01 PR.DS-02 |
11.6. Encryption in Transit
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.6.1 | Encrypted communication transiting Authority owned and / or supplier managed infrastructure must be designed to support content inspection capabilities as per SS-006 Security Boundaries Security Standard [Ref. A]. | PR.DS-02 |
11.6.2 | Encrypted communications channels must be protected using protocols, protocol suites and techniques in accordance with the relevant cryptographic manual, the DWP Approved Cryptographic Algorithms document [Ref. B] and require Digital Design Authority approval of the solution. | PR.DS-02 |
11.6.3 | Encrypted sessions must re-negotiate new symmetric keys after one of the following criteria is met: The data volume specified in the validation has exceeded its maximum limit; The time limit specific in the validation has exceeded its maximum limit. | PR.DS-02 |
11.6.4 | Logon and privileged functions must be cryptographically protected to prevent credential leaks. | PR.DS-02 |
11.7. Encryption at Rest
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.7.1 | All user-writeable partitions on Authority devices (including laptops, mobile phones, portable storage devices etc.) must be encrypted at the media-level (i.e. Full Disk Encryption (FDE)). | PR.DS-01 |
11.7.2 | Where applicable, the master encryption key must reside within assured cryptographic hardware and must not leave the assured cryptographic hardware for the master keys’ service life. | PR.DS-01 |
11.7.3 | Information held encrypted at rest must also be integrity protected. | PR.DS-01 |
11.7.4 | Where multiple layers of encryption are available (e.g. media-level and database field-level), each layer must be applied proportionally to mitigate risks identified during a risk assessment process. | PR.DS-01 |
11.7.5 | The encryption software deployed on devices as described in 11.7.1 must require sufficient entropy as part of the authentication mechanism. In a scheme that uses a password as the authentication mechanism, this equates to a password that is of sufficient length and complexity to match the requirements in the password policy defined for the system. | PR.DS-01 |
11.7.6 | Encryption software deployed on devices (i.e. laptops, portable storage devices etc.) must restrict the number of authentication attempts within any given time interval. Where the number of attempts and time interval are not specified as part of the product’s certification, these values must be configured in line with the password policy for the system/device in question. | PR.AA-03 PR.DS-01 |
11.8. Passwords
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.8.1 | For password-based cryptography, incorporating cryptographic salts (i.e. adding random data to passwords before encryption) adds an extra layer of security. Authentication information which grants authorised access to asset(s) must: not be stored in plain text or in any reversible format; be salted with at least 128 bits of pseudorandom data; be hashed using a method described in the DWP Approved Cryptographic Algorithms Document [Ref. B]. | PR.DS-01 PR.AA-03 |
11.9. Cryptographic Key Management
(Important) this table contains ‘must’ activities.
Reference | Minimum Technical Security Measures | NIST ID |
---|---|---|
11.9.1 | Cryptographic keys must be managed and protected in accordance with the controls present in SS-002 PKI & Key Management Security Standard [Ref. D]. | PR.DS-01 |
12. Appendices
Appendix A - Security Outcomes
The minimum security measures defined in this standard contribute to the achievement of security outcomes described in the table below. For consistency, the official NIST Sub-category IDs have been carried through to the standards.
Table 2 – List of Security Outcomes Mapping
Ref | Security Outcome (sub-category) | Related security measures |
---|---|---|
PR.AA-03 | Users, services, and hardware are authenticated | 11.7.6, 11.8.1 |
PR.DS-01 | The confidentiality, integrity, and availability of data-at-rest are protected | 11.1.1, 11.1.3, 11.1.4, 11.1.6, 11.2.1, 11.2.2, 11.2.4, 11.2.5, 11.2.6, 11.2.7, 11.2.8, 11.3.1, 11.3.2, 11.4.1, 11.5.1, 11.7.1, 11.7.2, 11.7.3, 11.7.5, 11.7.6, 11.8.1, 11.9.1 |
PR.DS-02 | The confidentiality, integrity, and availability of data-in-transit are protected | 11.1.1, 11.1.3, 11.1.4, 11.1.6, 11.2.1, 11.2.2, 11.2.4, 11.2.5, 11.5.1, 11.6.1, 11.6.2, 11.6.3, 11.6.4 |
PR.PS-01 | Configuration management practices are established and applied | 11.1.4 |
PR.PS-02 | Software is maintained, replaced, and removed commensurate with risk | 11.1.2, 11.1.3, 11.1.4, 11.1.5, 11.2.3 |
PR.PS-03 | Hardware is maintained, replaced, and removed commensurate with risk | 11.1.4, 11.1.5 |
DE.CM-09 | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events | 11.1.7 |
Appendix B - Internal references
Below, is a list of internal documents that should read in conjunction with this standard.
Table 3 – Internal References
Ref | Document | Publicly Available* |
---|---|---|
A | SS-006 Security Boundaries security standard | Yes |
B | DWP Approved Cryptographic Algorithms | No |
C | SS-023 Cloud Computing Security Standard | Yes |
D | SS-002 PKI and Key Management Security Standard | Yes |
E | SS-033 Security Patching Standard | Yes |
F | DWP Security Assurance Strategy | No |
*Request to access to non-publicly available documents should be made to the Authority.
Appendix C - External references
The following publications and guidance were considered in the development of this standard and should be referred to for further guidance.
Table 4 – External References
Document |
---|
NIST SP 800-57 Part 1 Revision 5 – Recommendation for Key Management: Part 1 - General |
NIST Special Publication 800-107 Revision 1, Recommendation for Applications Using Approved Hash Algorithms |
Transitioning the Use of Cryptographic Algorithms and Key Lengths (nist.gov) |
NIST SP 800-132, Recommendation for Password-Based Key Derivation Part 1: Storage Applications |
What Is Post-Quantum Cryptography? – NIST |
NCSC: Post-Quantum Cryptography – what comes next ? |
Appendix D - Abbreviations
Table 5 – Abbreviations
Abbreviation | Definition | Owner |
---|---|---|
CPA | Commercial Product Assurance | NCSC |
CTR | Counter | Industry |
DDA | DWP Design Authority | DWP |
DH | Diffie Hellman | Public |
FDE | Full Disk Encryption | Industry |
FIPS | Federal Information Processing Standard | NIST |
HMAC | Keyed-hash Message Authentication Code | Industry |
ISO | International Organisation for Standardization | ISO |
KDF | Key Derivation Functions | Industry |
MAC | Message Authentication Code | Industry |
NCSC | National Cyber Security Centre | NCSC |
NIST | National Institute of Standards and Technology | NIST |
NIST CSF | NIST Cyber Security Framework | NIST |
PDU | Produce Delivery Units | DWP |
PRF | Pseudorandom Functions | Industry |
PKCS | Public Key Cryptography Standard | RSA Security |
PKI | Public Key infrastructure | Industry |
RBG | Random Bit Generator | Industry |
RDP | Remote Desktop Protocol | Microsoft |
SHA | Secure Hash Algorithm | Industry |
SSD | Solid State Drives | Industry |
SSH | Secure Shell | IETF |
TLS | Transport Layer Security | IETF |
TPM | Trusted Platform Module | Industry |
USB | Universal Serial Bus | Industry |
VM | Virtual Machine | Industry |
Appendix E - Glossary
Table 6 – Glossary
Term | Definition |
---|---|
Initialisation Vector (IV) | A binary vector used as the input to initialize the algorithm for the encryption of a plaintext block sequence to increase security by introducing additional cryptographic variance and to synchronize cryptographic equipment. |
Public Key Infrastructure (PKI) | The architecture, organization, techniques, practices, and procedures that collectively support the implementation and operation of a certificate-based public key cryptographic system. Framework established to issue, maintain, and revoke public key certificates. |
Message Authentication Code (MAC) | A cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data. |
PQC | Post-Quantum Cryptography, also known as Quantum Resistant Cryptography, refers to cryptographic algorithms that are resistance to quantum computing attacks. |
Quantum Computing | Quantum computing leverages the properties of quantum physics to perform operations that are impossible or impractical for classical computers. |
Trusted Platform Module (TPM) | A tamper-resistant integrated circuit built into some computer motherboards that can perform cryptographic operations (including key generation) and protect small amounts of sensitive information, such as passwords and cryptographic keys. |
Appendix F - Accessibility artefacts
A variety of accessibility guidance is available from the below URL, that includes:
Guidance and tools for digital accessibility
Understanding accessibility requirements for public sector bodies