Is there a recommended cryptoperiod for HMAC hashing keys? I have an application that receives certain pseudo-random input values and computes their keyed hash using HMAC-SHA256. The hashing key itself is 256-bits long, generated at random by a CSRNG.

Two questions:


Which category does the hashing key fall under in NIST's 2016 Recommendations? Is it a "Symmetric Data Encryption Key"?
If it doesn't fall under any of those categories, is there a recommended cryptoperiod for it, or can I use it ad eternum?


(I suspect that this is an irrelevant detail, but the pseudo-random input values the application is processing are themselves HMACs of other input values. However, they are computed by a third party. So, since I do not know or have access to the hashing key they use, I'm treating them as "pseudo-random.")
Theoretically as pointed out by @CodesInChaos there is no need to rotate keys as long as they remain secret.

Also as @CodesInChaos points out, you need to architect the system for key rotation in the event of key compromise. 

The best way to do that is to build key rotation into the app and operational tooling, and then put procedures in place to rotate keys regularly. That way you know key rotation will actually work when you really need it. 

During the Heartbleed incident there were banks that were unable to re-key many of their certificates for several months despite regulator requirements that they be changed immediately. Rekeying was an infrequent manual process on their varied and ancient systems; some had never been re-keyed and nobody in house knew how to do it. It simply couldn't be done in a timely manner.

Regular exercise of key rotation prevents this sort of problem. Automation makes it easy. Think of it as DR planning and testing for your crypto keys.