Cookie duration is easy to set and easy to forget. You pick a value once during the build. Then it sits there for years. That gap causes bugs in your data and risks in your consent.
Here is what the setting does. A cookie is a small file in the browser. Its life comes from the Max-Age or Expires value in the code. A session cookie ends when the browser closes. A persistent cookie stays for a set time, from hours to years.
The rules are clear on this. The ePrivacy Directive says most cookies should not last more than 12 months. The EDPB treats a life over 13 months as a problem unless you can justify it. Many bodies also say you should ask for consent again every 6 to 12 months.
Now the technical side. Browsers can override your value. Safari caps first-party cookies at 7 days. Cross-site cookies drop to 24 hours. So a 90-day setting means little for a large part of your users. Third-party scripts add their own cookies too, and some run for two years. If your policy says 90 days but a tag sets 730 days, your own site breaks its own rule.
This is why teams should review cookie duration on a plan. A simple flow works well. Scan every cookie and list its name, source, and life. Match each life to its purpose. Cross-check against your consent records. Fix and write down what you changed.
