How should suppliers use assurance levels in interface agreements?

What assurance levels should an interface agreement actually define?

An assurance level is the agreed security depth for a specific interface, not a generic supplier label. It should describe the strength expected for authentication, authorisation, message integrity, diagnostics, and update paths, so the integration team knows what must be demonstrated before the interface is allowed to operate.

The agreement should be precise about scope. One interface may need stronger identity proofing, stronger cryptographic protection, tighter logging, or more restrictive administrative access than another, and the assurance level should capture that difference instead of assuming one company-wide standard fits every connection.

For interface agreements that use assurance language, the most useful question is whether the stated level can be tested and evidenced. If the level cannot be translated into controls, verification steps, and acceptance criteria, it is too vague to govern a real integration.

How assurance levels shape evidence, ownership, and change control

Assurance levels are only useful when they become operational obligations. The agreement should assign ownership for each control domain, define the evidence needed to prove the required depth, and state who approves exceptions or temporary deviations before release.

This is where the interface agreement becomes a control document rather than a commercial appendix. Evidence might include test results, design artefacts, configuration records, or signed acceptance, but the exact form matters less than whether both parties can verify the stated assurance level in practice.

Change control also has to be part of the assurance statement. If the interface, credentials, certificates, message format, diagnostic route, or update channel changes, the assurance level may no longer hold, so the agreement should require re-verification before the altered interface is trusted again.

When suppliers use a formal certification or assurance scheme as the reference point, they should still translate it into interface-specific obligations. The broad scheme may define the baseline, but the agreement must say what that means for this particular connection, this particular data flow, and this particular operational dependency.

For teams building or reviewing assurance language, NHIMG’s Audit, Assurance and Compliance Guide is useful when you need to turn attestations and evidence into a governable process. Where the interface is governed under certification terms, the EU Cybersecurity Act and EUCS Guide explains how assurance levels translate into practical certification expectations.

What good supplier wording looks like for interface assurance

Good wording is specific enough that an engineer, auditor, and service owner would all read it the same way. It should identify the assurance level, the interface boundaries it applies to, the parties responsible for each control, and the conditions under which the interface must be paused, re-tested, or re-approved.

A strong agreement also distinguishes between the steady-state control set and the higher bar required for administrative or recovery paths. Diagnostic access, break-glass routes, and update channels often need different treatment from normal message exchange because they can expose deeper system authority if misused.

That distinction matters because an interface can be “secure enough” for routine traffic while still being under-specified for maintenance, incident handling, or emergency change. The assurance level should therefore cover the full lifecycle of the connection, not only the happy path in production.

Supplier teams that want a general model for assurance terminology can use the ISO/IEC 29115 guide to think clearly about assurance depth, while the NIST SP 800-63 Digital Identity Guidelines provide a widely recognised reference for authentication assurance and federation decisions.

Practitioner Guidance

What to verify: Confirm that the assurance level is tied to one named interface, not a supplier-wide promise. If the document cannot show how authentication, authorisation, integrity, diagnostics, and update control are evidenced, it is not yet enforceable.

Decision rule: If a change can alter trust, access, or recovery behaviour, require re-approval before deployment. Treat updates to credentials, certificates, privileged routes, or diagnostic access as assurance-impacting changes, not routine housekeeping.

What good looks like: The agreement gives both sides the same acceptance test, the same owner for each control, and the same trigger for revalidation. That alignment is what prevents disputes after an incident or failed integration.

Practitioner takeaway: Use assurance levels to make interface security measurable and re-checkable, not ceremonial, because the value is in turning an abstract security expectation into a specific release gate.

Related resources from NHI Mgmt Group

• How should security teams use public trust badges without overclaiming assurance?
• How should security teams use a maturity assessment without mistaking it for assurance?
• How should security teams set assurance levels in digital onboarding?
• When should teams use stronger identity assurance instead of basic authentication?