Identity principles
Section 3: General identity good practice
- Last reviewed
- 8 June 2026
- Owner
- Head of Architecture
5. Provide end-to-end encryption
Systems must protect the end-to-end communications between the system and consumer to prevent common attacks and to protect data.
Why this is important
Many malicious activities involve monitoring network activity with commonly available tools to gather credentials and system data. Modern protocols do not expose data as they provide a level of encryption within the authentication token. Older authentication protocols and legacy methods (username/password) could expose data which could be exploited to gain access by impersonating a user.
End-to-end encryption is common when accessing external systems but must also be implemented as standard for internal systems to protect against any insider threats within DfE.
How to do this
You should:
enable transport-level encryption for all communications between consumer and system and system to system
ensure the protocol used is secure and supported
ensure that ongoing support for the system includes the ongoing management of certificates and processes to renew and upgrade as necessary
6. Provide a mature and appropriate access model
Systems must utilise a suitable access model so that it can be secured and managed appropriately.
Why this is important
Access models ensure administrators and consumers of a system are granted the appropriate level of access for their requirements. The levels of access and the roles provided should be appropriate to the relevant system and the data or control it grants access to.
A relatively simple system may only require user, administrator and approver roles. A system managing access to confidential data across multiple education establishments would require a rich access model to manage both role access and to segregate data access accordingly.
How to do this
You should:
review requirements for the access model as part of the discovery phase, considering the data being accessed and by whom
review and agree the appropriate access model in advance with the relevant compliance teams to ensure that the model is developed in-line with the wider solution and not as a post-development activity
utilise existing measurements such as Levels of Assurance to review the appropriateness of the access model within a system
ensure that the security model is reviewed as part of the selection criteria for COTS products
ensure that COTS and in-house developed systems provide a flexible and extensible access model which can be updated and amended as required
7. Enable just-in-time access for administrative permissions
High-privilege and high-access roles must be assigned on a time-bound basis and used appropriately and only when required.
Why this is important
Accounts which carry large amounts of privileged access are targets for malicious activity and inappropriate use. A malicious user who can gain access to an account which included numerous administrative roles could cause significant damage within DfE.
Assigning roles using a just-in-time (JiT) model ensures that administrators and privileged users are provided with the access required but only when required. The security for this can be further enhanced by using multi-factor authentication to ensure that administrators verify the access request appropriately.
The use of just-in-time access also instils more mature working practices, as administrators need to plan changes and use administrative permissions appropriately. It also avoids the potential of accidental misuse by ensuring that the permissions are applied explicitly rather than implicitly.
How to do this
You should:
ensure that COTS products are selected, and that these can either integrate into existing security capabilities which can provide JiT access, or which can support JiT access natively
ensure that internally developed products integrate into existing security capabilities which can provide JiT access
provide a support model which includes full alignment to the JiT access model with defined approvers for access requests if necessary
8. Secure system and machine accounts
System accounts are powerful and must be managed and secured appropriately to avoid misuse or malicious exploit.
Why this is important
System (aka service) accounts are used for system-to-system access or to run unattended activities within a system, and often require high-privileged access to do so.
The system accounts often have a password which is set once and rarely updated. This can lead to either future exploits if this password is identified or system outage if maintenance is required but the password is no longer known.
System accounts are often assigned unnecessarily high-privileges by the system owners or developers for convenience rather than applying the correct least-privilege level of access. Due to this they are often targeted by malicious users as they can be used to gain significant levels of access without detection.
How to do this
You should:
ensure that system accounts are identified within system designs, along with details of the permissions assigned and usage so they can be monitored for anomalous activity
ensure that permissions assigned to system and machine accounts align to least-privilege and are not given generic administrative access
use Managed Service Accounts on Windows platforms if compatible
use complex passwords which are stored securely and not shared
do not allow interactive logins to ensure that the accounts can only be used for its intended purpose
ensure that operational processes are established for maintaining the accounts and resetting credentials on a 6 to 12 month basis
9. Support relevant secure separation requirements
Data held within systems must be segregated to enable access controls and support potential future divestment or separation requirements.
Why this is important
Data held within systems will contain end-user identifiable and sensitive information which must be segregated and protected accordingly so that access controls can be enforced.
The architecture of the system must also support requirements for future potential separation or divestment within DfE. The separation and segregation within the system should ensure that data relating to specific organisations or providers can be identified and extracted as required.
This segregation will also support this principle to ensure the access model for a system can enforce data separation accordingly.
How to do this
You should:
ensure that data architecture within the system supports the separation between organisations, consumers and so on
ensure that data within the application can support extraction and removal of specific data types without requiring re-architecture of the solution
10. Consider requirements for Multi-Factor Authentication (MFA)
Systems should utilise additional authentication factors as standard to protect against malicious activity.
Why this is important
MFA is often considered an additional control required when accessing systems as an administrator or when accessing high-value data which needs to be protected. However, it should be seen as a more general measure which is used to protect access to systems provided by DfE. The use of MFA has multiple benefits, not just for accessing administrative roles or high-value data.
MFA serves as a conscious reminder that a user is accessing a system which requires additional verification to access. This may make the user more aware of their responsibilities and consider how and where they are accessing a system.
Common malicious attacks against systems utilise password brute-force attacks to attempt to guess a user’s credentials and gain access. The use of MFA will stop this attack as system access will require both a username/password and an MFA challenge.
Users and suppliers will often share credentials for convenience, allowing multiple people to access the same system using the same username/password. The use of MFA restricts this poor practice as it provides the ‘something you have’ authentication challenge, which may be a secure token, an SMS code or a prompt on an app on a user’s mobile phone.
How to do this
You should:
discuss and review requirements for MFA as part of the system’s discovery phases, and review with an information security colleague if necessary to confirm whether it is a hard requirement
consider MFA requirements when a system undergoes a significant change to scope, such as the addition of new functionality and/or access to additional data
consider the platforms used to access the system (principle 2) and review if MFA would be supported on all platforms. If not possible across all platforms, review a two-tier approach for access, with platforms unable to support MFA only given access to a sub-set of functionality and/or data.
11. Integration into central reporting/SIEM for auditing
Systems must integrate into DfE's SIEM (security information and event management) platform, to provide security oversight and assurance.
Why this is important
While individual system owners or teams have a responsibility for the security of their systems, the Cyber and Information Security division have a DfE-wide responsibility to monitor for and protect against malicious activity and cyber threats. Integrating systems into DfE’s SIEM platform provides the broad visibility of the health of all systems. It also enables the ability to discover and monitor any emerging threats and vulnerabilities across the estate.
How to do this
You should:
align to Principle 1 enables integration and logging for the authentication into a system, as this is provided as part of the service
follow standard Departmental Security Assurance Model (DSAM) processes to ensure the InfoSec team are aware of any sensitive data or access within the system
12. Support role segregation and separation of duties
Systems must utilise a role model which ensures that roles are managed and segregated appropriately.
Why this is important
Many systems include workflows to support processes for approval, code promotion and changes to data held within. Separation of duties (SoD) refers to the checks and balances within a process to ensure that the relevant governance and approvals are carried out.
Separating the steps of a workflow or approval process ensures that a task such as code promotion, approval of additional privilege or granting access to an application or data set, is suitably scrutinised.
Individuals should not be able to approve end-to-end lifecycle activity or promote their own access rights unless there has been a conscious decision to do so. Self-promotion or self-approval may be suitable for specific low-privilege or low-impact activities, but this must be reviewed with assurance teams to ensure it is acceptable.
How to do this
You should:
ensure alignment with Principle 5 to provide a mature access model which will be sufficiently granular to support SoD.
review workflows and approvals required within the system and capture roles and SoD details within system designs
ensure any self-promotion or self-approval processes and workflows are reviewed and approved by assurance teams
13. Utilise policy-based access controls
Systems should consider policy-based and attribute-based access controls to provide modern and flexible access methods.
Why this is important
Traditional role-based access control (RBAC) methods of managing access to systems provide granular access models and methods to ensure that access is proportionate for the end-user. However, they do require additional ongoing management to maintain the correct group membership and ensure that permissions are not being collected and retained unnecessarily.
A future move to policy-based access control systems will provide greater flexibility and adaptive controls. These will change automatically as the end-user’s attributes change (for example, job role or provider).
The use of policy-based access controls requires a reliable set of master data records and therefore may not be possible for all attributes at present, but in-house development and COTS systems should consider this requirement so they can be adapted in the future.
How to do this
You should:
ensure that COTS and in-house developed apps can support modern policy-based and attributed-based authentication models
architect systems for delegated controls where the Identity platform provides authentication and coarse-grained access, and the application retains responsibility for fine-grained access via user attributes
14. Adhere to least-privilege model
Roles and privileges assigned to systems must be appropriate for the user’s requirements.
Why this is important
Providing permissions and access which are aligned to the end-users’ requirements ensure that access to data is protected appropriately and avoids the ability for malicious activity or accidental misuse.
An administrator who is provided with full access to a system for simplicity or due to a poorly designed access model could inadvertently or otherwise cause damage to the system or access data inappropriately.
Managing access to the least-privilege model also ensures that impacts from malicious activity from a stolen or impersonated account are restricted.
How to do this
You should:
not use generic built-in roles for systems (for example, domain admin, owner, administrator)
ensure that the security model is reviewed as part of the selection criteria for COTS products and supports least-privilege
ensure that internally developed systems provide a granular permissions model which supports least-privilege
ensure that COTS and in-house developed systems provide an extensible access model which can be updated and amended as required
manage the use of high-privilege roles appropriately, with time-bound access or with separate ‘break-glass’ accounts