How to Rotate Recovery Lock Password 1 Hour After Viewing for Existing Enrolled Macs?

​@mvu ​@leecacioppo ​@Chubs ​@dletkeman ​@BookMac : Could you please help here.

Thanks for that,
Great write up!

I’m almost positive it can be achieved with the new routines that has yet to be released due to the “open nature” of how it works. 
 

Otherwise in the interim - if you have power automate, n8n, or something similar - then a solution can be put together for it. 

Hi — I haven’t implemented this workflow myself. This is based on Jamf docs, older Nation threads, and public write-ups I found (including with AI-assisted search). Treat it as a research summary, not a battle-tested runbook.  I’m also using AI to summarize and format everything so treat with a grain of salt.

Short version: the ~1 hour rotate-after-view behavior is tied to PreStage + a Jamf-generated random Recovery Lock password. SET_RECOVERY_LOCK via the API will set/update the lock and store the password in inventory, but it does not appear to enroll that record in Jamf’s scheduled rotator. There also does not appear to be a supported “Recovery Lock password was viewed” event you can hang automation on.

Why PreStage machines rotate and API-set ones don’t

Jamf Pro 10.33 added Recovery Lock password rotation:

Password rotation applies to passwords that are randomly generated by Jamf Pro. Viewing the password in the computer’s inventory information automatically enables Jamf Pro to generate a new, random password for that computer 60 minutes after the password was viewed.
https://docs.jamf.com/10.33.0/jamf-pro/release-notes/New_Features_and_Enhancements.html

That matches what you see on PreStage-enrolled Macs.

Setting the lock after enrollment is a different path. Jamf’s article covers POST /api/v2/mdm/commands with commandType: SET_RECOVERY_LOCK and newPassword. That works (as you’ve already proven). It stores the password in Jamf. It does not say that this also starts the 60-minute rotation timer.
https://learn.jamf.com/en-US/bundle/technical-articles/page/Recovery_Lock_Enablement_in_macOS_Using_the_Jamf_Pro_API.html

This same gap showed up on Nation back in 2022. On the “Recovery Lock API” thread, the consensus was that key rotation after view was only supported when Recovery Lock was enabled through PreStage:
https://community.jamf.com/general-discussions-2/recovery-lock-api-26473

Dan Snelson ran into it from the other direction: view the recoveryOS password via API / Self Service, then ask Jamf to do the scheduled rotate. He confirmed with Jamf Support that GUI view → scheduled rotate worked, but SetRecoveryLock - Scheduled was not available on the API, and opened feature request JN-I-25769:
https://snelson.us/2022/06/view-recoveryos-password/

Detecting “password viewed”

I could not find a Recovery Lock equivalent of LAPS audit history.

LAPS does expose who viewed the password and when:

GET /api/v2/local-admin-password/{clientManagementId}/account/{username}/{guid}/audit
https://developer.jamf.com/platform-api/reference/get_v2-local-admin-password-clientmanagementid-account-username-guid-audit-1

Recovery Lock only has the view endpoint itself, e.g.:

GET /api/v2/computers-inventory/{id}/view-recovery-lock-password

https://developer.jamf.com/jamf-pro/reference/get_v2-computers-inventory-id-view-recovery-lock-password

Calling that endpoint is viewing the password. It is not a history feed.

Webhooks also don’t list a Recovery Lock view event. The documented events are things like ComputerAdded, ComputerCheckIn, ComputerInventoryCompleted, RestAPIOperation, etc.:
https://developer.jamf.com/jamf-pro/docs/webhooks-1

Inventory/Smart Groups can tell you Recovery Lock is enabled or not, not when the password was last shown:
https://learn.jamf.com/en-US/bundle/technical-articles/page/Jamf_Pro_Reporting_Capabilities_for_Apples_macOS_Security_Features.html

Jamf Routines templates (as of the public list I saw) are things like Slack/Teams notify, rename, restart, update EA — not Recovery Lock view detection:
https://www.jamf.com/blog/jamf-routines-workflow-automation-introduction/

So I would not plan on:

• Jamf webhooks
• Smart Groups / EAs
• Routines
• a public Recovery Lock audit API

…to fire “wait 1 hour, then SET_RECOVERY_LOCK.”

RestAPIOperation might fire if someone hits the view endpoint via API. GUI “Show Password” is a different path and is not documented as a webhook. Even if it showed up in audit logs, that doesn’t look like a supported automation trigger the way LAPS audit is.

Practical options for already-enrolled Macs

1. Don’t try to clone PreStage 1:1.
Treat the API-set cohort as “set unique random password + rotate on a schedule + rotate again after any real use.”

Scheduled SET_RECOVERY_LOCK is a common pattern. One public example is the Inetum-Poland GitHub Action (OAuth client credentials, optional Smart Group scope, issues SET_RECOVERY_LOCK):
https://github.com/Inetum-Poland/jamf-recovery-lock-rotation

There are also older group/search-based scripts for “we enrolled before PreStage had Recovery Lock,” e.g.:
https://github.com/chrisgzim/Jamf-API-Recovery-Lock-by-Group
https://gingerscripting.com/setting-an-apple-silicon-recovery-lock-password-through-the-jamf-api/

Use /api/v2/mdm/commands rather than the old /api/preview/mdm/commands path.
https://community.jamf.com/general-discussions-2/set-recovery-lock-password-api-deprecated-32533

2. If you really need “view starts a 1-hour clock,” wrap viewing.
Don’t have techs use Inventory → Show Password for those legacy Macs. Put view behind an internal tool / Self Service / helpdesk script that:

1. Calls view-recovery-lock-password
2. Shows the password
3. Records {managementId, viewedAt}
4. One hour later sends a new random SET_RECOVERY_LOCK

That’s basically Snelson’s idea, except you own the scheduler because Jamf’s scheduled command isn’t on the API.

Keep API credentials off managed Macs. Jamf explicitly recommends against running credentialed scripts from the fleet in the Recovery Lock API article above.

3. Ask Jamf for the product fix.
Useful request text:

• Apply the existing 60-minute rotation-after-view to Recovery Lock passwords set via SET_RECOVERY_LOCK, not only PreStage-generated ones
• Expose SetRecoveryLock - Scheduled (JN-I-25769)
• Add a Recovery Lock view-audit API like LAPS

Re-enrolling those Macs through ADE/PreStage with random Recovery Lock would get native behavior, but that’s usually a much bigger operational cost than scheduled API rotation.

I think ​@Chubs is probably right with what he says.

To be honest, we don’t check that box in our prestage instance. But your write up made me think! 🤔

Did you reach out to Jamf support yet? 

Update: I’ve submitted a feature request with Jamf for this functionality.

The request is to support automatic Recovery Lock password rotation after the password is viewed for existing/enrolled Apple Silicon Macs, including devices where Recovery Lock was set using the Jamf Pro API.

If you have the same requirement, please upvote the feature request to help increase its visibility:

JPRO-I-2278: https://ideas.jamf.com/ideas/JPRO-I-2278

Thanks for your support!

Upvoted!

Upvoted!

Sorry for the delay, i was in a Jamf 270 Course this week and unfortunately i also don’t have a solution for that. :(