Spring Security 7: MFA, Modular Config, and What Breaks

Spring Security 7 dropped at Spring I/O 2026. Daniel Erno from the Spring Security team gave a talk covering the biggest changes. Here's what matters if you're building Java apps with Spring Boot.

Multi-Factor Authentication (MFA) — The Big One

This feature was requested 12 years ago (issue #2603, opened November 2013). It finally shipped.

What it does: You can now enforce MFA at the application level or per-endpoint. Spring Security tracks which authentication factors each user has completed and when they authenticated.

Key classes:

FactorGrantedAuthority — records what factor you used (password, one-time token, etc.) and when you used it
@EnableMultiFactorAuthentication — enables MFA across your app
AllRequiredFactorsAuthorizationManager — combine multiple MFA rules

Site-wide MFA example:

@EnableMultiFactorAuthentication(authorities = {
    FactorGrantedAuthority.PASSWORD_AUTHORITY,
    FactorGrantedAuthority.OTT_AUTHORITY
})

Now every protected endpoint requires both password login AND a one-time token.

Per-endpoint MFA (more practical):

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    var mfa = new AllRequiredFactorsAuthorizationManager.Builder()
        .requiredFactor(FactorGrantedAuthority.PASSWORD_AUTHORITY)
        .requiredFactor(FactorGrantedAuthority.OTT_AUTHORITY)
        .build();

    http.authorizeHttpRequests(authZ ->
        authZ
            .requestMatchers("/public.html").permitAll()
            .requestMatchers("/admin.html").access(mfa.hasRole("admin"))
            .anyRequest().authenticated()
    );
    return http.build();
}

Time-based rules: You can require that an authentication is recent. For example, force users to re-authenticate before changing their password:

var recentPassword = AllRequiredFactorsAuthorizationManager.builder()
    .requiredFactor(FactorGrantedAuthority.PASSWORD_AUTHORITY, Duration.ofMinutes(5))
    .build();

http.authorizeHttpRequests(authZ ->
    authZ.requestMatchers("/change-password")
        .access(recentPassword)
);

If a user logged in 30 minutes ago, they get redirected back to login before accessing the password change page.

Why this matters: Before Spring Security 7, you had to implement MFA yourself or use a third-party library. Now it's built into the framework.

Modular Configuration — Stop Replacing Boot Defaults

The old problem: When you created a SecurityFilterChain bean, you replaced Spring Boot's entire security configuration. You had to manually add form login, session management, CSRF protection, and OAuth2 defaults. Miss one, and your app breaks.

The new way: Instead of a full SecurityFilterChain bean, provide a customizer that changes only what you need:

// OLD: replaces ALL defaults
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(authZ ->
        authZ.requestMatchers("/public.html").permitAll()
              .anyRequest().authenticated()
    );
    return http.build();
}

// NEW: keeps Boot defaults, only changes what you need
@Bean
Customizer<HttpSecurity> httpSecurityCustomizer() {
    return http ->
        http.authorizeHttpRequests(authZ ->
            authZ.requestMatchers("/public.html").permitAll()
        );
}

Spring Boot's form login, CSRF, session management, and OAuth2 Authorization Server defaults stay intact. You only customize the parts you change.

Targeted customizers: You can also customize specific configurers without touching the full HTTP security:

// Change only OAuth2 Authorization Server defaults
@Bean
Customizer<OAuth2AuthorizationServerConfigurer> authServerCustomizer() {
    return authz -> authz.oidc(oidc ->
        oidc.providerConfiguration(pc ->
            pc.claims(c -> c.claim("conference", "Spring I/O 2026"))
        )
    );
}

This is cleaner. No more SecurityFilterChain beans unless you really need to override everything.

What Got Removed

OAuth2 Password Grant — gone. If you're using password grant type, migrate to authorization code. The OAuth 2.1 spec calls password grant "legacy." Spring Security removed it from the client library.

and() DSL — gone. The old chain-style configuration with .and() is removed. Use lambdas instead:

// OLD (removed)
http
    .authorizeHttpRequests(authZ -> authZ
        .requestMatchers("/admin").hasRole("ADMIN")
        .anyRequest().authenticated())
    .and()
    .formLogin();

// NEW (lambda style)
http
    .authorizeHttpRequests(authZ -> authZ
        .requestMatchers("/admin").hasRole("ADMIN")
        .anyRequest().authenticated())
    .formLogin(Customizer.withDefaults());

Open Rewrite can automate this migration for you.

Module reorganization: AccessDecisionVoterManager moved to spring-security-access package. Kerberos and Authorization Server modules now share the same version number (7.x).

OAuth2 Changes

PKCE is now the default. The Authorization Server enforces Proof Key for Code Exchange. Clients must send a code challenge. If you have legacy clients that can't support PKCE, you can turn it off:

http.oauth2AuthorizationServer(authz ->
    authz.tokenEndpoint(token -> token
        .requireProofKey(false) // disable PKCE (not recommended)
    )
);

Dynamic Client Registration. Authorization Servers can now register clients through a REST endpoint (/oauth2/register). This was added mainly for MCP (Model Context Protocol) support, where AI tools like Claude Desktop need to dynamically register themselves as clients.

The endpoint requires a token with client.create scope. Each token can register exactly one client. After registration, the token is discarded.

Warning: Don't open this endpoint without access control. The spec authors recommend authenticated registration, not open registration. Open registration is a denial-of-service risk.

HTTP Service Clients with OAuth2

Spring Framework 7 introduced HTTP Service Clients (declarative, interface-based HTTP clients). Spring Security 7 adds OAuth2 token injection support.

// Define as an interface
@HttpServiceExchange(url = "http://localhost:8090/api/hugo")
interface HugoService {
    @GetExchange
    List<String> getNominees(@RequestParam int year);
}

// Register the bean with OAuth2 support
@Bean
HugoService hugoService(HttpServiceProxyFactory factory, OAuth2AuthorizedClientManager manager) {
    return factory.createClient(HugoService.class);
}

// Enable OAuth2 token injection
@Bean
OAuth2RestClientHttpServiceGroupConfigurer oauth2Configurer(
        OAuth2AuthorizedClientManager manager) {
    return OAuth2RestClientHttpServiceGroupConfigurer.fromOAuth2AuthorizedClientManager(manager)
        .clientRegistrationId("default-client");
}

No more manual RestClient request interceptors. The token injection happens automatically.

MCP Security

Model Context Protocol (MCP) gets security support through Spring AI, not Spring Security core. The MCP spec changes too frequently for Spring Security's release cadence.

Start with Spring Initializr: Add the MCP server starter with security:

spring-ai-starter-mcp-server-security

For clients:

spring-ai-starter-mcp-client-security

Both depend on the Authorization Server for dynamic client registration and token management. The security flow is OAuth2-based: metadata discovery, client registration, authorization code flow, token exchange.

Should You Upgrade?

If you're on Spring Security 6: Plan the migration now. The and() DSL removal and SecurityFilterChain changes will require code updates. Open Rewrite handles most of the migration automatically.

If you're starting a new project: Spring Security 7 is the right choice. MFA is built in, configuration is simpler, and OAuth2 defaults follow current best practices (PKCE enforced, no password grant).

If you use Kerberos or OAuth2 Authorization Server: Versions are now aligned with Spring Security 7. No more separate version tracking.