A schema compatibility mode decides whether a new event schema can be read by old consumers, new consumers, or both. In a registry using BACKWARD, upgrade consumers first. With FORWARD, upgrade producers first. FULL allows either order. NONE turns the checks off and shifts the risk to you.
The modes
The Confluent Schema Registry documentation defines them.
- BACKWARD: consumers on the new schema can read data written with the previous schema.
- FORWARD: consumers on the previous schema can read data written with the new schema.
- FULL: both of the above.
- NONE: compatibility checks are disabled.
- Transitive variants: check the new schema against all earlier versions, not just the latest.
The default is BACKWARD, and it is non-transitive, so a new schema is compared only with the latest version.
Upgrade order
The same page gives the order. For BACKWARD, upgrade consumers before producers begin writing the new schema. For FORWARD, upgrade producers first, then consumers. For FULL, they can be upgraded independently. With NONE, no checks happen, so plan the rollout by hand.
It also lists a special case: Kafka Streams supports only the BACKWARD and FULL families, and the page says to upgrade Streams applications before the upstream producers.
Why this is a security topic
Schemas are an input contract. A consumer that reads a field it does not expect, or a field whose meaning changed, can misbehave in ways that look like bugs but behave like vulnerabilities: a role field that now holds a different value set, an amount field whose unit changed, a nullable field that used to be required.
Compatibility checks catch the structural cases. They do not catch meaning changes, so reviews still need a human question: does any consumer make a security decision from this field?
Practical rules
- Pick the mode on purpose and write it in the topic or subject documentation.
- Prefer the transitive variant when old data stays in the log for a long time and consumers may replay from the start.
- Do not set NONE to unblock a deploy. Add the field as optional instead.
- Restrict who can register or change schemas. Write access to the registry is a form of write access to every consumer's input.
- Still validate in the consumer. A schema says the shape is right, not that the values are sane.
Replay and long retention
Event logs can be replayed months later. A consumer built today must read what was written under older schemas. That is the argument for transitive modes and for keeping deserialization code that handles old versions.
Related reading
Access control on the log itself is a separate layer. See Kafka ACLs for least privilege.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Which side upgrades first under BACKWARD?
Consumers, before producers start writing data in the new schema.
Does a compatible schema mean safe data?
No. It checks structure, not values. Consumers should still validate what they read.
Sources
Last reviewed: 19 October 2026.
