Hi all, Working on a personal-use kernel extension (not for distribution, just my own Mac) and hitting a wall between Reduced Security and notarization. A lot of existing threads on this are from 2018–2022, so hoping someone can confirm what's still current. Setup: Apple Silicon, macOS 27 (Golden Gate beta) Boot Security Policy: Reduced Security with "Allow user management of kernel extensions from identified developers" enabled (confirmed via bputil -d) Standard $99/year Developer Program membership Kext signed with a standard Developer ID Application cert (via normal CSR through Keychain Access) What happened: codesign -dvvv shows a clean signature — valid Authority chain, correct TeamIdentifier, timestamped. No issues. But kmutil load -p rejects it: Authenticating extension failed: Bad code signature I understood from an older DTS reply that notarization was the missing piece, so I ran it through notarytool. Upload/auth succeeded, but the result came back Invalid: { "severity": "error", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": "arm64e" } Question: Is a standard Developer ID Application cert genuinely insufficient for kext notarization, and is the kext-signing entitlement (via /contact/kext/) still the only way to get a cert with the right extension (OID 1.2.840.113635.100.6.1.18)? Or has this changed for personal use recently? Apple's own Contact page for that form says: "You don't need to request a certificate to sign your kernel extension for personal use... signature checking can be disabled as described in the SIP Guide." That implies Reduced Security + personal kext shouldn't need the special cert — but my results suggest otherwise. Am I missing a step, or is there a documentation gap? Happy to share kmutil print-diagnostics output if useful. Thanks!