What should security teams do when SOAP and REST coexist in the same programme?

They should assign one control owner for API governance, one inventory, and one evidence model for reviews and audits. SOAP and REST can coexist safely, but only if access policy, monitoring, and testing are standardised across both. Without that, each protocol accumulates a different kind of blind spot.

Why SOAP and REST Need One Governance Model, Not Two

Coexistence is usually a programme governance problem before it is a protocol problem. SOAP and REST differ in message shape, authentication patterns, payload handling, and the tooling teams use to test them, so separate ownership often produces uneven policy enforcement and inconsistent evidence. OWASP’s Non-Human Identity Top 10 is useful here because many API controls fail when service credentials, tokens, and trust relationships are managed inconsistently across interfaces. In practice, many security teams discover the gap only after audits, integration failures, or one protocol being monitored more closely than the other.

How SOAP and REST Coexist Without Creating Two Security Postures

The practical goal is not to force SOAP and REST into the same technical design, but to make them answer to the same governance model. That means one inventory, one policy baseline, and one review path for controls such as authentication, authorisation, logging, change approval, and testing evidence. SOAP endpoints often sit behind heavier enterprise integration patterns, while REST endpoints are commonly exposed more broadly and built by more distributed teams. The security risk appears when those different operating patterns produce different exceptions, different monitoring thresholds, or different interpretation of who owns a failing control.

A useful operating pattern is to treat the programme as one API estate with multiple interface types:

Classify every SOAP and REST endpoint under the same service catalogue so the owner, data sensitivity, and exposure level are visible in one place.
Apply the same minimum control intent across both, even if the implementation differs, so an access rule or logging requirement does not disappear because the protocol changes.
Use shared review criteria for authentication, schema validation, rate limiting, and test evidence, then allow protocol-specific technical checks where needed.
Track exceptions centrally so temporary SOAP-specific or REST-specific deviations do not become permanent policy drift.

For programmes that are already split by team or vendor, the biggest gain usually comes from standardising evidence and review rather than rewriting every control. A single governance layer also makes it easier to spot gaps where one interface family is well tested but the other is only assumed to be covered. Where teams rely on different gateways, frameworks, or contract-testing approaches, the assurance model breaks down if reviewers cannot compare like with like.

This approach becomes weaker when the estate is so fragmented that no shared owner can enforce the baseline, or when legacy SOAP integrations and externally facing REST APIs are governed by unrelated funding, tooling, or risk decisions.

Common Variations and Edge Cases in Mixed API Programmes

Tighter standardisation often increases coordination overhead, so organisations have to balance speed of delivery against the cost of one shared control model. That trade-off matters most when SOAP is embedded in older enterprise systems and REST is used for newer customer-facing or partner-facing services.

One common variation is a split between internal and external exposure. If SOAP remains internal and REST is public, the minimum baseline may be the same while the control depth differs. Another variation is ownership by platform: teams may run SOAP through an enterprise integration layer and REST through an API gateway, but that does not remove the need for one accountability model. The toolchains can differ; the evidence standard should not.

There is also a genuine consensus gap on how much protocol-specific tailoring is acceptable. Some organisations prefer strict uniformity, while others allow different implementation patterns as long as the control objective is identical and measurable. The safer rule is to standardise outcomes, then document where protocol-specific handling is unavoidable. That is especially important when one interface type has stronger legacy dependencies, because inherited exceptions tend to become hidden control debt.

Where organisations mix SOAP and REST with machine-to-machine integrations, shared governance becomes even more important because the trust relationships are often long lived and difficult to audit consistently.

Risk and Threat Considerations

Mixed SOAP and REST programmes can create uneven exposure when one interface family receives stronger monitoring, weaker authentication review, or less consistent testing than the other. The risk is not the coexistence itself, but the creation of parallel security assumptions that drift over time.

Failure mechanism: Different teams often apply different gateway rules, logging depth, schema validation, or access review cycles to SOAP and REST. That inconsistency can leave blind spots in credential abuse, misconfiguration, and API misuse, especially where service-to-service trust is long lived and difficult to rotate or revoke cleanly.

Impact: The organisation may lose confidence in its audit evidence, miss exposed endpoints, or fail to detect an access path that is effectively stronger on one protocol than the other. In a mixed estate, the weakest interface often becomes the easiest place for attackers or careless integrations to inherit excessive reach.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	16	Mixed SOAP and REST estates need consistent API security requirements and validation coverage.
Recommendation: Use one security baseline for both interface types and test it consistently across the estate.
NIST CSF 2.0	GV.OV-01	The question is fundamentally about one owner and one governance model across the programme.
Recommendation: Assign clear accountability so SOAP and REST are governed as one risk surface.
OWASP Non-Human Identity Top 10	NHI-01	SOAP and REST often rely on machine-to-machine credentials that need one inventory and owner.
Recommendation: Track service credentials and interface ownership centrally to prevent hidden trust paths.
MITRE ATT&CK	T1078	Mixed API estates can expose reused or over-privileged service accounts across protocols.
Recommendation: Assume credential misuse is a shared API risk and verify access paths uniformly.
NIS2	Article 21	The question concerns standardised governance, monitoring, and testing across a critical programme.
Recommendation: Maintain comparable control measures and auditability across both API families.

Practitioner Guidance

What to prioritise: Establish one accountable owner for the API estate and one minimum control baseline before teams argue about protocol-specific tooling. That baseline should define the evidence that proves access, logging, and testing are actually being applied, not just documented.

What to verify: Check whether SOAP and REST are being reviewed against the same questions for ownership, exposure, exception handling, and credential governance. If the answers differ by team rather than by risk, the programme has a governance gap, not a technical preference.

Common mistake: Treating the older SOAP estate as “already controlled” and the newer REST estate as “naturally better governed.” Mixed programmes often fail because each side inherits a different blind spot, and neither side is assessed against the same evidence standard.

Practitioner takeaway: The right target is not identical implementation, but identical accountability and assurance, because once SOAP and REST are governed differently, the control model fragments faster than the technology does.