Client policies work by voting. On each event every condition in the policy is asked whether it applies, and the policy needs at least one yes before the executors in its profile run [17]. `ClientIdUriSchemeCondition` has exactly one case in its switch statement, `PRE_AUTHORIZATION_REQUEST`, and every other event falls through to `default` and returns `ABSTAIN` [14]. This is a deliberate design choice, not an oversight: pre-authorization is the only stage where a `client_id` that happens to be a URL means anything, because no client has been resolved yet [15].
`PKCEEnforcerExecutor` is built for the other half of the lifecycle. It acts on four events: `REGISTER` and `UPDATE`, where it auto-configures and validates the pin on a proposed client, and `AUTHORIZATION_REQUEST` and `TOKEN_REQUEST`, where it checks the live request [16]. One voting event plus four acting events gives five distinct events with none shared [21]. On the event the condition votes on, the enforcer has no handler; on the events the enforcer handles, the only condition in the policy abstains, and for a single-condition policy an abstention is the entire vote [20]. Add a second condition that votes on `AUTHORIZATION_REQUEST` and the policy can be satisfied by that one instead [18].
The missing pin reads better as inheritance than as a PKCE hole. The same provisioned client came up with no `basic` scope, and therefore no `sub` claim, no audience mapper, and none of the realm's capability scopes [7]. A provisioned client takes the realm's default client scopes, and in a realm where every client had always named its own, none had ever been declared [8]. The executor reads from a level this realm never populated.
The transfer feature follows the same pattern. It exists for a draft standard where a client identifies itself by URL instead of pre-registering, and it gets switched on because that is how an MCP client registers with an authorization server it has never met [9]. You are exposed if two things hold: the feature is on, and your S256 floor lives in each client's own JSON [5] rather than in a policy whose conditions vote on the live authorization and token events [12]. Declare default client scopes and pin PKCE through a policy that fires on live requests, and the same inheritance runs in your favour.
Keycloak already says the shape of this out loud. The Server Administration Guide's Conditions evaluation section notes that some condition types are evaluated in all request types while others only during certain requests, that "in some cases, it may not be obvious whether particular condition is evaluated or not", and that you should test your scenarios [10]. That text lives in the guide covering client policies, but the guide that walks admins through enabling the feature omits it at 26.7.1 or 26.7.3, and so does the page as published on 2 September 2026 [11]. Meanwhile the admin console shows the enforcer sitting inside the profile, which is accurate and no help whatsoever [19].
What catches it is a live authorization request with `plain`, or with no `code_challenge` at all, against a client the executor built [3].
