The Hardened Runtime is a macOS protection that stops certain classes of attack on a running app, such as code injection and library hijacking. Apple's notarization service requires it. Most apps run fine with it on. If yours needs a blocked capability, you add a narrow entitlement for it.
Definitions
An entitlement is a key in an app's code signature that asks for a specific capability or exception. The Hardened Runtime, together with System Integrity Protection, protects the runtime integrity of your software. Apple says it prevents classes of exploit like code injection, DLL hijacking and process memory space tampering.
You turn it on in Xcode under Signing and Capabilities, by adding the Hardened Runtime capability to your target. For manual signing, it is a flag at signing time.
What it blocks by default
Apple says the Hardened Runtime does not affect most apps, but it disallows less common capabilities, such as just-in-time compilation. The exception entitlements Apple documents cover things like:
- Creating memory that is both writable and executable
- Letting dynamic linker environment variables influence the app, which can be used to inject code
- Acting as a debugger that attaches to other processes
- Sending Apple events to other apps, which can prompt the user
Each of these has a Boolean entitlement, and the default for all of them is false.
The rule for exceptions
Apple's guidance is to use only the entitlements that are absolutely necessary for your app to function. Treat each one as a deliberate loosening of a protection, and write down why it exists.
A few practical habits help:
- Start with none. Enable the Hardened Runtime, run your test suite, and add an exception only when something specific breaks.
- Map each entitlement to a feature. For example, an app that embeds a scripting engine may need the JIT exception, and nothing else needs it.
- Review the list at every release. An exception added for an old plug-in can outlive the plug-in.
Apple also notes that when Xcode signs your code, it includes an entitlement only when the value is true. If you sign manually, follow that convention and leave false entitlements out of the file.
Plug-ins and host apps
Entitlements go on executables. Apple states that shared libraries, frameworks and in-process plug-ins inherit the entitlements of their host executable. The notarization documentation adds that plug-ins do not declare their own entitlements, so a host app must include every entitlement its plug-ins need, even when the plug-ins are notarized separately.
That has a security cost. If your host app disables library validation so one plug-in can load, every other library in that process is covered by the looser setting. Apple's advice is not to disable library validation for executables that do not host plug-ins, because library validation protects them from loading untrusted code.
System extensions
Apple notes that macOS refuses to load system extensions that use Hardened Runtime exception entitlements, with one narrow exception for non-DEXT system extensions. If you ship a system extension, check the current Apple documentation before you plan around exceptions.
Where Safeguard fits
The Hardened Runtime protects an app while it runs. It does not tell you which third-party libraries are inside it. Safeguard's dependency scanning and SBOM generation cover that side. A free scan is at gold.safeguard.sh/scan.
Quick check
Do I need the Hardened Runtime to notarize a Mac app?
Yes. Apple lists it as a requirement of the notary service, and says you must enable it to upload a macOS app for notarization.
Do all apps need exception entitlements?
No. Apple says the Hardened Runtime does not affect the operation of most apps. Add an exception only for a capability your app truly needs.
Can a plug-in add its own entitlements?
No. Plug-ins inherit the entitlements of the host process, so the host must declare what the plug-ins need.
Sources
Last reviewed: 19 October 2026.
