Think of the AC as a password to log in to the PUF, and the keycodes as encrypted versions of your keys. To store some key securely, you encrypt it with the PUF, which generates a keycode that you can write to flash (or other storage), then you can decrypt the keycode with the PUF to get your key back.
Every time you enroll your PUF, you get a new AC. To be able to decode any keycodes you've generated with the PUF you need to re-init the PUF with the same AC on your next boot. So you'll need a safe place to store the AC, which the FFR (PFR?) provides. Since it's a dedicated part of the device flash, it can also be used by the secure boot and PRINCE systems - if you store it elsewhere they wouldn't know where to find it, and if you're using PRINCE to transparently encrypt the flash they wouldn't be able to decode the data. A bit of a chicken and egg problem.
In addition to the AC and the keycodes for secure boot and PRINCE there's place for one user keycode, so if all you need is one key you can store it there. If you need more keys you'll need to store them elsewhere, after encrypting them with the PUF to get keycodes to store them more securely. Or you could generate additional keys derived from the user key in FFR by encrypting various suitable constants with the user key.
If you use the ffr_keystore_write() function, make sure you don't write "bad" data or you'll brick your device like I did in https://community.nxp.com/t5/LPC-Microcontrollers/Bricked-LPC55S28-by-writing-partial-key-data-to-FF... 🤷
Note: this is my interpretation of the PUF and related systems, hopefully someone from NXP will clear things up if I'm wrong!
