The Security Profile is the baseline for mitigating the attacker model with OAuth and OpenID Connect controls. The Message Signing profile is a separate advanced option for cases that need non repudiation across FAPI messages. It adds signed requests and responses, including HTTP Message Signing for resource interactions, so teams should adopt it only when stronger evidentiary assurance is required.
How the Security Profile and Message Signing Profile differ in practice
The FAPI 2.0 Security Profile is the baseline profile: it focuses on the OAuth and OpenID Connect controls needed to mitigate the standard attacker model for high assurance financial APIs. The message signing profile is not a replacement for that baseline. It is an added option for cases where the interaction itself needs stronger evidentiary assurance than transport and token controls provide.
That distinction matters because the two profiles solve different problems. One is about securing the authorization and token flow well enough for the FAPI threat model. The other is about making specific FAPI messages tamper evident and more defensible after the fact, which is why it introduces signed requests and responses.
When teams compare them, the key question is not which is “better”, but which assurance property they need. If the need is standard high-security API access, the Security Profile is the usual target. If the need includes stronger proof around who sent a message and whether it changed in transit, Message Signing becomes relevant.
What Message Signing adds beyond the baseline
Message Signing adds cryptographic signing of requests and responses, and it can extend to HTTP Message Signing for resource interactions. That means the receiving party can verify integrity and origin at the message level, rather than relying only on channel security, bearer token handling, or the broader OAuth and OpenID Connect protections defined by the baseline profile.
This extra layer is most useful when the organisation needs evidence for disputes, non-repudiation, or high-value transaction workflows. It is a deliberate increase in complexity: more key and signature handling, more implementation surface, and more operational care than the baseline profile alone.
In other words, Message Signing does not simply harden the same control set a little further. It changes the assurance model. The baseline says the flow is protected against the FAPI attacker model; Message Signing says particular messages can also be attested as signed artefacts with stronger evidentiary value.
How to choose between them for a FAPI deployment
The practical decision is whether your business and assurance requirements need message-level evidence or only secure authorization flow. If the API is used for ordinary high assurance access, the Security Profile is usually sufficient and easier to operate. If the workflow carries legal, financial, or dispute-sensitive consequences, signed messages may justify the added overhead.
Teams should also remember that Message Signing is a separate advanced option, not a default checkbox. Adopt it only when the extra assurance changes the outcome of the design review, the audit story, or the dispute-handling process. If those conditions are absent, the added implementation burden usually outweighs the benefit.
For engineering teams, the right comparison is operational as much as technical: baseline controls reduce attack exposure, while signed messages strengthen proof. That is why the profiles can coexist in one program without being interchangeable.
Risk and Threat Considerations
Message signing reduces ambiguity, but it also creates its own failure modes if keys, canonicalisation, or signature verification are handled inconsistently. A deployment that treats signatures as optional metadata, or that cannot validate them reliably across intermediaries, may believe it has evidentiary assurance when it does not.
Failure mechanism: If the signing workflow is not enforced end to end, an attacker or misconfigured integration can still replay, alter, strip, or mis-handle messages in ways that defeat the intended non-repudiation property.
Impact: The organisation may inherit a false sense of assurance, with disputes, fraud investigations, and transaction integrity reviews becoming harder instead of easier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | FAPI relies on strong digital authentication and federation assurance. |
| Recommendation — Apply phishing-resistant assurance and federation controls to strengthen the OAuth/OIDC baseline. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | FAPI profiles are designed to reduce API authentication abuse and token misuse. |
| Recommendation — Harden client and user authentication paths to prevent token abuse and session confusion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Message signing depends on secure lifecycle handling of signing keys and related credentials. |
| AU-10 — Non-repudiation | Message Signing is explicitly about stronger evidentiary assurance and non-repudiation. | |
| SC-12 — Cryptographic Key Establishment and Management | Signed request and response workflows depend on trustworthy key establishment and handling. | |
| Recommendation — Manage signing keys tightly and rotate them on a defined lifecycle. Enable cryptographic evidence controls where transaction attribution must be defensible. Protect the signing key lifecycle and enforce approved cryptographic use. | ||
Practitioner Guidance
What to prioritise: Decide first whether your requirement is security of the authorisation flow or evidentiary assurance over the message itself. If you cannot articulate a non-repudiation or dispute-resolution need, do not add signing just because it sounds stronger.
What to verify: Make sure signature validation is mandatory, canonicalisation rules are consistent across both sides, and key management is operationally realistic for the full message lifecycle. The control only helps if every party can produce and verify the same signed artefact reliably.
Practitioner takeaway: Use the Security Profile as the baseline for FAPI threat mitigation, and treat Message Signing as an explicit assurance upgrade for workflows where proof matters more than simple access control.
Related resources from NHI Mgmt Group
- What is the difference between commit signing and SBOMs for code security?
- What is the difference between image signing and registry access control in container security?
- What is the difference between a trust profile and a one-off security questionnaire response?
- What is the difference between a quality profile and a quality gate in application security governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
