Java 24 permanently disabled the Security Manager under JEP 486. Starting a JVM with one enabled now fails, and installing one at run time throws an exception. If your app or a library relied on it for sandboxing, move to container, OS or process isolation before upgrading past Java 23.
What happened
JEP 411 deprecated the Security Manager for removal in Java 17. JEP 486 finished the job in JDK 24:
- Enabling it at startup with
-Djava.security.manager=allow,defaultor a custom class is an error, and the JVM exits. - Calling
System.setSecurityManagerthrowsUnsupportedOperationExceptionwith the message "Setting a Security Manager is not supported." - The API methods remain but do nothing useful, and they will be removed in a later release.
On JDK 24, System.getSecurityManager returns null and AccessController.doPrivileged runs the action immediately.
How to check your application
The JEP gives a checklist you can run on JDK 17 to 23:
- Look in launch scripts, docs and configuration for Security Manager options or policy files.
- Run the app and watch for deprecation warnings.
- Run it with
-Djava.security.manager=disallow. A custom manager installation will throwUnsupportedOperationException. - Scan with
jdeprscanfor deprecated calls such asSystem::setSecurityManager.
Do not forget dependencies. Older application servers and plugin hosts are a common place to find a manager.
What to use instead
| What you used it for | Alternative named by the JEP |
|---|---|
| Sandboxing untrusted code | Containers, hypervisors, or OS mechanisms such as seccomp |
| Blocking calls like System.exit | Change the source, use static analysis or rewriting, or a Java agent that rewrites bytecode |
| Library code calling doPrivileged | Stop calling it; it simply runs the action on 24 |
A key point: the Security Manager was never a strong isolation boundary for hostile code. The replacement is a boundary outside the JVM.
Upgrade order
If you find a dependency on it, do the work on your current JDK first. Remove the manager, replace the isolation, and prove it with tests. Then upgrade the runtime in a separate change. That way a failure points to one cause.
Try it yourself
The vulnerability management demo shows how findings are triaged by risk. Treat an unmet runtime requirement the same way: record it, assign an owner and a date.
Click through it at your own pace, or open it full screen.
Safeguard can scan Java dependencies and containers to show what a service ships. The free scan is at gold.safeguard.sh/scan.
Quick check
Is the Security Manager removed or just disabled?
Per JEP 486 it is permanently disabled in JDK 24. The API classes stay for now and are expected to be removed later.
Does this affect me if I never set a policy file?
Probably not directly, but a library or server you use might. Run the disallow test to find out.
Sources
Last reviewed: 19 October 2026.
