# What is an exposure report for secrets? > An exposure report lists which secrets a person or credential received, when and from where, so you know what to reissue after they leave or leak. URL: https://crunu.com/learn/exposure-report Language: en Updated: 2026-10-30 An exposure report is a record, built from a system's logs, of which secrets a particular person, device or credential actually received, which versions, when and from which addresses, so that after a departure or a compromise you can tell which values to treat as known and replace. ## The question it answers When someone leaves, two different questions come up, and most tools only answer the first: - **What could they access?** Their permissions: the projects, paths or environments they were allowed to read. - **What did they receive?** The specific values and versions delivered to them, as opposed to what they were merely allowed to see. Permissions tell you the upper bound. Delivery tells you what is already out. A developer allowed to read production for two years but who fetched it twice, eight months ago, exposed the values as they were eight months ago. Values created after that, and values changed since, weren't part of what they received. ## Why "delivered" is the right unit A record of deliveries is conservative in a useful way. It can't prove a person read a value, only that the value reached their device. Treat delivered as seen. It also can't cover copies made outside the system, such as a value someone pasted into a note. So an exposure report is a floor, not a ceiling: everything on it should be reissued; things off it may still need judgment. ## Common mistakes - **Reissuing everything.** Without a delivery record, the safe answer is "replace every value they could ever read". That is often weeks of work, and in practice it doesn't get finished. - **Reissuing only what they had at the end.** Access that was removed months ago can still have delivered values that are still in use. - **Short log retention.** A report is only as long as the logs behind it. If delivery logs expire after 30 days, the report covers 30 days. - **Losing the report.** It is evidence for auditors and for anyone who later asks whether a value was exposed. Keep it with the record of what you reissued. ## The exposure report in Crunu The Crunu server keeps a delivery record: which versions of which environments each person, machine or service token received, when, how many times and from which address. It can't see the values, only that encrypted versions were served. When an owner or admin removes a member, the wizard's first step shows the exposure report built from that record: for each environment, the person's access, the versions they received, when, from which addresses, and whether they had the current environment key or an earlier one. *Figure: Example: Kiteline removes Tom Halvorsen in four steps. The exposure report shows which versions of which environments he received, when, and from which addresses, up to version 14 of payments-api / production. His access is removed and the keys of his six environments are rotated in the admin’s browser, with production in progress as five of six. The report lists 34 values to reissue at providers, by name only, and says that what’s been seen can’t be revoked. A card shows the server knows only what it served, never the values.* Next to it is the **reissue checklist**. Your browser compares the versions the person received with the current ones, so a value changed since their last fetch drops off the list. Only file paths and variable names are shown, never values. The report can be downloaded for your security team; keep it, because it lives on the wizard's page. A worked example and the limits of this kind of report are in [who saw which secret](https://crunu.com/blog/who-saw-which-secret-exposure-report), and the full departure process in [what to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation).