Organisations spend considerable effort securing their databases, APIs, and identity systems. Then they email sensitive financial reports as unencrypted PDF attachments to distribution lists.
The distribution channel often undoes everything upstream. A quarterly earnings report sent to an email alias that includes a former employee. A client portfolio statement forwarded to a spouse's personal account. A regulatory filing in a team inbox accessible to everyone in the finance department. These are not theoretical scenarios — they are routine failure modes in organisations that have not deliberately designed their report distribution model.
Report distribution is a data security problem that does not get the same attention as the systems that produced the data. This post covers the threat model, the distribution patterns ranked by security strength, what meaningful auditability looks like, and the common pitfalls that allow sensitive reports to reach unintended recipients.
The Threat Model for Report Distribution
Understanding what you are defending against is the starting point for designing the right distribution pattern. Report distribution threats cluster into five categories.
Lateral access. An internal employee accesses a report they are not intended to see — because the report was delivered to a shared folder, a team inbox, or a storage location with permissive access controls. The data was never meant to leave the authorised group, but an access control gap allows it to. This is the most common failure mode and the least dramatic — it rarely triggers an incident response, but it routinely violates data minimisation principles and, in regulated industries, creates compliance exposure.
Forwarding. A legitimate recipient shares the report with someone outside its intended audience — knowingly or not. Once a PDF attachment has been sent, the sender has no mechanism to control who receives it next. A client sends their portfolio statement to their accountant. An employee forwards a salary report to the wrong distribution list. The document travels beyond its authorised boundary with no mechanism to detect or stop it.
Long-lived access. A download link with no expiry, a shared credential in a script, a stored access token in a browser — any of these creates a persistent access point that outlasts its intended use. The employee who last refreshed the report pipeline left the company two years ago, but their personal access token is still embedded in the script.
Shared inbox exposure. A report delivery system that sends individual client reports to a single team inbox — "reports@company.com" — means every member of that team has access to every client's documents. Individually sensitive reports delivered to a collectively accessible inbox collapse the access model entirely.
Orphaned access. An employee leaves, a vendor relationship ends, a client account closes — but access to reports generated during that relationship remains active. Without a deliberate deprovisioning step, former stakeholders can continue accessing reports they are no longer entitled to.
Access Patterns, Ranked by Security Strength
No single pattern fits every use case. The right choice depends on the sensitivity of the report, the nature of the recipient relationship, and the operational overhead your team can sustain.
Direct email attachment. The simplest pattern and the weakest. The PDF is generated and attached to an email delivered to the recipient's inbox. Once sent, there is no mechanism to revoke access, detect forwarding, or log access events beyond the original delivery. Appropriate for low-sensitivity internal reports where the operational overhead of a more controlled pattern is not justified. Inappropriate for reports containing personally identifiable information, financial data, or client-specific content.
Expiring download link. A time-limited URL is generated and included in the delivery email. The recipient clicks the link within the expiry window to download the report. Better than a direct attachment — the access window is bounded, and access can be logged at the link level. Still forwardable: anyone who receives the link can use it before it expires. Appropriate for moderately sensitive reports where a bounded access window is sufficient and recipient identity verification is not required.
Per-recipient generation. A unique PDF is generated for each recipient, optionally including recipient-identifying information (name, account identifier, or a visible or invisible watermark). A forwarded copy is traceable to the original recipient. Combined with a delivery mechanism that logs the generation event, this pattern creates a record of which recipient received which version of the report. Appropriate for individually addressed client or employee documents.
Authenticated portal. Recipients authenticate to access their reports — through a username and password, or through an identity provider via SSO. Access is controlled at the identity level: only authenticated, authorised users can retrieve their documents. Access can be revoked immediately by deprovisioning the user. Access events are logged against the authenticated identity. This is the strongest distribution pattern for sensitive reports with identified recipients. The operational overhead is higher — it requires user provisioning and management — but it eliminates the forwarding and orphaned access threats.
Iframe embedding with session-scoped access. Reports are displayed within an authenticated application context — embedded in a client portal, an internal dashboard, or a workflow tool. The recipient never receives a downloadable PDF directly; they view the report within an authenticated session that they already hold. Access is bounded by the session and controlled by the application's existing authentication and authorisation model.
Auditability: What You Actually Need to Know
Audit for report distribution means being able to answer two distinct questions.
What was generated? When was the report produced, from what inputs, using which template version, for which recipient? The generation event is fixed at the time of creation. It is the authoritative record of what was sent — if the figures in a delivered report are later questioned, the generation record is the evidence.
Who accessed it? When did the recipient download or view the report, from which IP address or session, and how many times? This is the access event, and it is separate from the generation event. A report can be generated but never accessed (useful to know — perhaps the recipient never received the delivery email). A report can be accessed multiple times from different IP addresses (useful to know — may indicate the link was shared).
These two logs answer different questions. Combining them gives a complete picture of the document lifecycle: created, delivered, accessed.
The minimum useful audit record contains: a document identifier (unique per generated PDF), a recipient identifier, a timestamp, an access method (download, view, link, portal), and a source IP or session identifier. More granular logging is appropriate for regulated environments; this minimum set is sufficient for most incident response scenarios.
What auditability is not: tracking "who saw the PDF after it left your systems." Once a document has been forwarded beyond its intended recipient, you have no visibility into subsequent access. Auditability covers what happened within your controlled distribution channel — it is not a substitute for a distribution pattern that limits forwarding in the first place.
Common Pitfalls
Public storage buckets. A report generation pipeline that writes PDFs to cloud storage with public or overly permissive access controls. Reports become accessible to anyone with the URL, and in some cases, to search engine crawlers. This is a configuration error that is routinely discovered only after a data incident.
Forwarded email attachments. An organisation that has implemented strong access controls within its systems, then undermines them by delivering sensitive reports as email attachments that travel without any access control mechanism attached to them.
Shared inboxes for individual reports. Delivering per-client or per-employee reports to a team inbox — finance@, reports@, admin@ — that all members of the team can access. The recipient group for the delivery is not the intended recipient group for the content.
Long-lived credentials in automation scripts. A personal access token embedded in a report generation script, stored in version control, or shared with colleagues. The credential's effective lifespan is now indeterminate — it lives as long as the code does, across any fork, export, or copy of the repository.
Test data in production distribution. A report generated with real client data during development or testing, left in the production delivery pipeline or a shared test environment. Sensitive production data reaches unintended recipients because the test process used real data rather than anonymised equivalents.
How This Maps to CxReports
CxReports operates at two levels relevant to secure report distribution: securing access to the reporting system itself, and enabling the distribution patterns described above through its generation and delivery capabilities.
API authentication: PATs for server-side use only. The CxReports API uses Bearer token authentication via Personal Access Tokens. PATs carry the access level of the user who created them. The critical constraint: PATs should only be used in server-side, secured environments — not embedded in client-side JavaScript or shared in scripts. For client-side report embedding, the Nonce token mechanism provides a single-use token that converts to a session cookie on first use and cannot be replayed.
Nonce tokens for embedded viewing. The Nonce token flow — create a single-use token server-side, pass it to the client, embed the report in an iframe — implements the session-scoped access pattern described above. The recipient views the report within an authenticated application context; no downloadable PDF link is exposed. The token is usable once and expires, eliminating the long-lived link threat for embedded report viewing.
Workspaces for environment and data separation. Workspaces in CxReports are fully isolated: reports, templates, data sources, and users in one workspace have no access to another. Use separate workspaces for development and production environments to prevent test generation from affecting production delivery pipelines. Use separate workspaces per client, business unit, or data classification where strict isolation is required.
Roles for least-privilege access. Custom roles in CxReports allow granular control over who can view reports, who can edit templates, and who can modify data sources. A reviewer role with read-only access to reports; a designer role with template access but no data source configuration; an administrator role with full workspace access. Assign the minimum access required for each user's function — consistent with the least-privilege principle.
SSO. CxReports supports single sign-on integration, allowing user authentication to be managed through your existing identity provider. Users deprovisioned in the identity provider lose access to CxReports — eliminating the orphaned access threat for internal users.
Distribution security: the application layer. CxReports generates PDFs on demand via the REST API. The distribution pattern — whether direct delivery, expiring link, portal access, or per-recipient generation — is implemented in your application layer. CxReports provides the generation primitive; your application controls when, to whom, and through what mechanism the PDF is delivered.
Secure by Default Checklist
| Concern | Control |
|---|---|
| Client-side credential exposure | Use Nonce tokens for iframe embedding, not PATs |
| Long-lived link access | Implement expiry on any generated download URL |
| Shared inbox exposure | Deliver per-recipient reports to individual addresses only |
| Lateral access to reports | Assign least-privilege roles; separate workspaces by access boundary |
| Orphaned access after offboarding | Use SSO — deprovisioning in IDP removes CxReports access |
| Test data in production pipeline | Use anonymised or synthetic data in development workspaces |
| Public storage exposure | Enforce non-public access controls on any report storage bucket |
Documentation:
To review how CxReports fits into your secure document delivery architecture, talk to the team.