Situation

A SAP BTP extension was live and operating acceptably under an earlier access posture. Over time, the program tightened scopes, trust relationships, role collections, and separation-of-duty expectations to match production governance requirements. The same flows that once looked stable began to fail.

Surface symptom

Authorizations broke along user journeys that had previously worked. Technical-user shortcuts or broad privileges no longer covered weak assumptions. Teams described the change as regression introduced by security hardening, because the failing path had once been green.

Why internal handling did not converge

Security could show that the tighter posture was required. Application teams could show that the old path used to work. Platform teams could point to updated scopes, claims, destinations, or trust settings. The debate stalled because each team looked at change history rather than architectural legitimacy. The old path had not proven validity. It had depended on looseness.

What the issue actually was

This was an identity and integration boundary failure. The extension had become operationally dependent on an access posture that governance could not preserve. Hardening did not create the problem; it removed the protection that had been hiding it.

What an independent verdict would need to clarify

• Whether the former access path was ever legitimate for the target operating model.
• Which trust or scope assumptions must change versus remain non-negotiable.
• Whether the current design can survive least-privilege enforcement without architectural revision.
• What must be decided before more exceptions normalize the wrong identity contract.

Why this case matters

Post-go-live extensions often look stable until the organization begins acting like production governance actually matters. If hardening breaks the system, the issue is rarely just permissions. It is that the architecture was never governable under the intended identity posture.