ASD ISM 2045 Keep security measures and features intact when supporting application backwards compatibility
What it says
Application backwards compatibility does not compromise any security measures or features.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishLegacy support is a favourite way around modern defences, so keeping older clients, API versions, protocols or file formats working must never switch off, bypass or weaken any protection.
Backwards compatibility is what lets an application keep working with older things: earlier versions of its own interfaces (APIs), older client software, legacy protocols, old file and data formats, or settings carried over from previous releases. This control means keeping those older things working must never cost security. No compatibility feature may switch off, bypass, downgrade or water down any security measure or feature, whether that is authentication, access checks, encryption, input validation, logging or a platform protection the application relies on. It matters because legacy support is one of the easiest ways around modern defences. Attackers deliberately look for the old door left open for older users: an outdated protocol the server still accepts, an old API version that skips newer permission checks, or a sign-in method kept alive for older clients that avoids multi-factor authentication. By choosing (or forcing) the legacy path, they can intercept data, take over accounts or reach information they should never see, even though the current version of the application looks secure.
Free. Save your status, tasks and notes.
Why it matters
If backwards compatibility is allowed to weaken security, attackers can use the legacy path (an outdated protocol, a weaker sign-in method or an old API version) to get around the application's current protections, leading to intercepted data, compromised accounts and unauthorised access those protections were meant to prevent.
How to implement
Application owners and lead developers should identify every backwards compatibility path the application supports (older API versions and endpoints, legacy protocols and cipher suites, older client versions, old file and data formats, and compatibility modes or settings) by reviewing code, configuration and interface documentation, and record which security measures and features must apply to each path.
Developers should route legacy requests through the same shared security components as current ones (for example, common middleware in front of every API version and one validation routine for old and new file formats), so authentication, authorisation, input validation, encryption and logging cannot be skipped by older versions and new security features cover them automatically.
Developers and system administrators should configure the application to fail closed rather than fall back: set minimum protocol versions, allow only approved cipher suites and authentication methods, and reject connections or requests that cannot meet them instead of silently downgrading to a weaker option to keep an older client working.
Security testers should include every supported legacy path in pre-release security testing by running the same test cases against older API versions, older clients and legacy file formats as against the current version, and by deliberately trying to force a downgrade or reach old endpoints that bypass newer checks.
Security architects and change approvers should add a design and change review check that rejects any compatibility change requiring a security measure or feature to be disabled, relaxed or bypassed (such as re-enabling a deprecated protocol, turning off exploit protection or exempting older clients from sign-in controls), and require a secure alternative instead, such as upgrading or adapting the legacy side.
Keep it running
Treat every backwards compatibility path as part of the application's attack surface, including older API versions and endpoints, legacy protocols and cipher suites, support for older client versions, old file and data formats, and compatibility modes or settings. Whenever a release adds, keeps or changes one of these paths, confirm that authentication, authorisation, input validation, encryption, logging and every other security feature still apply to it in full, and that no new or strengthened security feature can be sidestepped through it.
Day to day, watch for fallback behaviour that quietly drops to a weaker option when a stronger one fails, and for support requests, vendor instructions or configuration changes asking for a security feature to be switched off or relaxed so an older component can keep connecting. Where compatibility can only be kept by compromising a security measure or feature, do not provide it that way: redesign it securely, upgrade or adapt the legacy side, or stop supporting that path.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask the application owner for a list of every backwards compatibility feature the application supports, such as older API versions, legacy protocols, older client versions, old file formats and compatibility settings.
Look at
Check whether each item shows which security measures and features apply to it, and whether any of them is reduced, bypassed or switched off for that path.
Good evidence
Every compatibility path is known, and each one receives the same security measures and features as the current version, with none weakened.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the security design or architecture showing how requests from older clients, API versions and file formats are handled.
Look at
Look at whether legacy requests pass through the same authentication, authorisation, input validation, encryption and logging as current ones, or through separate code that skips or lags behind them.
Good evidence
Legacy and current paths share one set of security enforcement, so no older version, client or format is exempt from any check, including newly added ones.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the application's protocol, cipher suite and authentication settings, along with its installation or operating requirements.
Look at
Check whether any weaker legacy option is enabled, or any platform security feature disabled, just so older clients or components keep working, and whether failed negotiation falls back to a weaker option.
Good evidence
Only current, approved options are enabled, failed negotiation is rejected rather than downgraded, and no platform security feature has been disabled or relaxed for compatibility.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the latest security test results, including tests of the application's supported older versions, clients, API versions and file formats.
Look at
Check that legacy paths were tested with the same security test cases as the current version, including attempts to force a downgrade or reach old endpoints that skip newer checks.
Good evidence
Every supported legacy path was tested, downgrade and bypass attempts failed, and any weakness found was fixed before release.
- Check 5 of 5What an auditor asks for
Ask for
Ask for design review or change records where a backwards compatibility feature was added, kept or changed, including any request to disable or relax a security feature for compatibility.
Look at
Look at how the security impact was assessed and what was decided whenever compatibility and security conflicted.
Good evidence
Conflicts were resolved without weakening security (for example, by upgrading or adapting the legacy side, or dropping that compatibility path), and no approved compatibility feature compromises a security measure or feature.
Mappings
Closest match in ISO/IEC 27001: A.8.26, Defining security requirements for applications, which this control depends on.
ISO/IEC 27001: 1 mapping
This control depends on A.8.26.
ISM-2045 requires organisations to ensure that maintaining backwards compatibility in applications does not weaken existing security measures or features. ISO/IEC 27001:2022 Annex A 8.26 relates by requiring security requirements to be identified and approved during application development or acquisition, which is where backwards compatibility requirements and constraints should be captured and assessed. Annex A 8.26 is broader and more process-focused across the full set of application security requirements, whereas ISM-2045 is a specific safeguard against security regression introduced by compatibility decisions.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.