A plain definition, a simple picture, and the sentence worth remembering.

Okta is an identity platform. It keeps the official list of who your people are, which applications each person may open, and how they prove who they are. Every day it records a huge number of events: sign-ins, failed attempts, password changes, factor enrollments, application assignments, and administrator actions. All of that activity is valuable, but in raw form it is overwhelming.

An Okta report is a prepared view of that activity or of the current state of your organization, organized to answer a common question. Instead of searching through thousands of log lines, an administrator opens the Reports area of the Admin Console, picks a report, chooses a time range or filter, and receives a table or summary. Many reports can be exported as a file, usually in comma-separated format that opens in a spreadsheet.

It helps to think of two kinds of questions that reports answer. The first kind is about activity over time: who signed in, how often, from where, and with which factors. The second kind is about the current state: who is assigned to which application right now, and which passwords look weak today. Both kinds matter. Activity shows behavior, and state shows exposure.

To feel why reports matter, imagine running an identity system with no summaries at all.

Identity systems create two kinds of risk. Some risks are loud, like an obvious attack. Others are quiet, like an old account that still has access to a sensitive application, or a group of users who never enrolled in multi-factor authentication. Quiet risks can sit unnoticed for years, because nothing about them is dramatic. They are found only by someone asking the right question and looking at the right data.

The questions leaders and auditors actually ask

What happens without reports

Without a ready way to answer these questions, teams fall back on manual detective work. Someone exports a list from one system, a second list from another, and compares them in a spreadsheet. The work is slow, error-prone, and rarely repeated. Findings arrive late and are often out of date by the time anyone acts. Audits become painful annual scrambles, when they should be a routine collection of fresh evidence.

How organizations moved from reading raw logs to asking questions of curated reports, and on to automated pipelines.

Where Okta reports fit today

Okta offers several layers of visibility. The System Log holds detailed raw events. Built-in reports present curated views for common questions. APIs and log streaming move data into your own tools for deeper analysis and long retention. Governance features add structured reviews of who has access to what. Reports sit in the middle: more approachable than the log, less flexible than your own analytics. Understanding that middle position tells you when to use them and when to reach for something else.

Ten terms carry the whole topic. Each is explained with what it is, why it exists, and where you will meet it.

Three questions to ask of any report

Whenever you open a report, ask three questions. What exactly does this measure? A sign-in report might count successful launches, failed attempts, or both. What period and scope does it cover? A report on the last seven days tells a different story than the last ninety. What would I do differently if the answer were bad? If nothing would change, the report may not be worth running regularly.

Okta offers several ways to see what is going on. Choosing the right one saves time.

Newcomers often confuse reports with the System Log, and the dashboard with both. They overlap, but each has its own purpose. Knowing the differences helps you reach for the right tool.

A simple rule of choice

An overview of the main kinds of reports, before we examine each family in its own chapter.

Okta groups its reports into families by purpose. The exact titles and groupings differ between releases, and Okta occasionally renames or reorganizes them, so treat the list below as a map of the territory rather than a catalog of menu labels.

How the families map to questions

A map of every part involved in producing and using an Okta report.

flowchart LR
  EV["User and Admin Activity"] --> LOG["Okta System Log"]
  APPS["Application Assignments and User Profiles"] --> DIR["Universal Directory"]
  LOG --> RPT["Reports Engine"]
  DIR --> RPT
  RPT --> VIEW["Admin Console Report Views"]
  VIEW --> CSV["CSV Export"]
  LOG --> API["System Log API"]
  API --> SIEM["SIEM or Data Warehouse"]
  CSV --> REVIEW["Review, Audit and Action"]
    

Walking through the boxes

User and admin activity. Everything starts with people and systems doing things: signing in, enrolling factors, changing passwords, assigning applications. Each action creates events.

System Log. Okta writes events into the System Log as they happen. This is the detailed record. Many activity reports are built on top of it.

Universal Directory and assignments. The current state of users, groups, and application assignments lives here. State reports draw on this information rather than on past events.

Reports engine. The component that takes your chosen report, filters, and time range, queries the underlying data, and builds an organized result.

Admin Console report views. The pages where administrators select and read reports, subject to their role and permissions.

CSV export. A way to save the results as a file for sharing, analysis, and evidence. Once exported, the data leaves Okta’s protections and becomes your responsibility.

System Log API. A programmatic interface to the same events, which lets your own tools build custom reports and long-term archives.

SIEM or data warehouse. External platforms that collect logs for security monitoring and analytics, often with longer retention than Okta provides by itself.

Review, audit, and action. The human end of the chain: where findings become tickets, fixes, and evidence.

A report is only as trustworthy as its source. Knowing the sources tells you what a report can and cannot say.

Okta reports draw from two broad kinds of sources. Understanding which kind a report uses explains most of its behavior: why it can look back only so far, why it may differ slightly from another view, and why some reports are snapshots.

Source type 1: recorded events

Activity reports are generally built from events that Okta recorded as things happened. A sign-in produces an event. A failed attempt produces an event. A factor enrollment produces an event. The report reads these events over the chosen time range, counts and groups them, and presents the result. Because the events are recorded in time order, these reports can answer “what happened between these dates.” They can only look back as far as the event data is retained.

Source type 2: current state

State reports read the present condition of the organization: which users are assigned to which applications, what the current profile attributes are, and what the present password health looks like. They answer “what is true now” and do not replay history. If you run such a report today and again next month, the difference between the two results is your own record of change, which is why saving dated exports matters.

Why two reports might not match exactly

The most commonly used family, showing who is signing in, to what, and how it went.

Sign-in reports answer the daily questions of any identity team. How many people are using single sign-on? Which applications are busiest? Are there unusual spikes in failures? Is multi-factor authentication being used as intended? These reports usually list events or counts for a period and can be filtered by user, application, or outcome.

What these reports typically show

Reading sign-in reports well

Numbers without context mislead. A rise in sign-ins on Monday morning is normal. A rise at three in the morning from an unusual country is not. Compare the current period with a similar earlier period, such as this Monday against the previous four Mondays. Look for the shape of the change, not just its size: a gradual climb in failures differs from a sudden spike, and each points to a different cause.

A report that looks at the quality of passwords people use for applications, without exposing the passwords themselves.

Some applications are connected to Okta through Secure Web Authentication, where Okta stores a username and password for the user and fills them into the application’s sign-in page. When users choose those passwords themselves, the passwords may be weak, reused across applications, or similar to each other. A password health report examines this population and highlights risky patterns. It is meant to show where passwords look risky, not to display the passwords.

What it helps you find

Turning findings into action

An important limit

This report covers only credentials that Okta can see in the form of stored application passwords for user-managed applications. It says nothing about passwords for applications outside Okta, or about users’ Okta passwords themselves, which are governed by password policies. Treat it as one useful lens, not a complete picture of password hygiene across the company.

Who has access, and who actually uses it. The foundation of access reviews and cost control.

Two questions come up in nearly every access conversation. The first is about assignments: who is currently allowed to open an application. The second is about usage: who actually does. The gap between those two numbers is where money is wasted and risk accumulates.

Assignment reports

Assignment reports list the current relationship between users and applications. You can usually view them by application, to see who has access to it, or by user, to see everything a person can open. They are state reports, so they show the present situation. They are central to least-privilege reviews, where the goal is to make sure each person has only the access they need.

Usage reports

Usage reports show how applications are actually used over a period: how many users launched them, how often, and when they were last used. They are activity reports and depend on the time range you choose. A long range, such as ninety days, is better for finding applications that nobody uses.

flowchart TD
  A["Assignment report: who has access"] --> C["Compare the two lists"]
  B["Usage report: who actually used it"] --> C
  C --> D{"Assigned but not used?"}
  D -->|"Yes"| E["Candidates to remove or review"]
  D -->|"No"| F["Access matches use"]
  C --> G{"Used by someone not assigned?"}
  G -->|"Yes"| H["Investigate: shared accounts, direct sign-in or bypass"]
  G -->|"No"| F
    

What the comparison tells you

Reports about the comings and goings of accounts and access, the heart of joiner, mover, and leaver control.

Identity teams describe the employee journey as joiner, mover, and leaver. Joiners arrive and need accounts and access. Movers change roles and need access adjusted. Leavers depart and need access removed. Lifecycle reports show what happened to accounts and access as these changes occurred, which lets you check that the process works.

What lifecycle reports help you check

Common leaver traps

Reports that highlight activity which may indicate an attack or misuse.

Not all activity is equal. Some patterns suggest that someone is probing, guessing, or abusing an account. Security-oriented reports gather these signals into views that make them easier to spot. They may include repeated failures, sign-ins from unusual places, blocked suspicious requests, and findings from Okta’s threat detection features, depending on your plan.

Signals these reports surface

From signal to response

What actually happens when an administrator opens a report, in plain language.

sequenceDiagram
  participant A as Administrator
  participant C as Admin Console
  participant R as Reports Engine
  participant D as Data Sources
  A->>C: Open Reports and choose a report
  C->>C: Check the administrator role and permissions
  A->>C: Pick filters and a time range
  C->>R: Request the report
  R->>D: Query logs and directory data
  D-->>R: Return matching records
  R-->>C: Build the results
  C-->>A: Show the report and offer an export
    

Step by step

Small habits that prevent big mistakes

Three settings decide whether a report tells the truth or tells a convenient half-truth.

Time ranges

Almost every activity report depends on the period you choose. A short range answers “what just happened.” A long range answers “what is the pattern.” Choose the range to fit the question, and be consistent when comparing. Comparing a thirty-day report with a seven-day report is a classic mistake that produces false conclusions.

Filters

Filters narrow a report to what matters. You might filter by one application, a group of users, a particular outcome such as failure, or a single person. Filters make reports faster and results easier to read. They also carry a trap: a filter that is too narrow can hide the very thing you are looking for. If a report shows nothing, check whether your filter is the reason before concluding that nothing happened.

Retention

Okta keeps event data for a limited time. The commonly cited period for the System Log is ninety days, though your plan and release may differ. After that, the data is gone from Okta’s view. Reports built on events cannot look further back than the retained data allows. This matters enormously for audits, which often cover a full year, and for incident investigations, which sometimes uncover problems months after they began.

The moment a report leaves Okta, it leaves Okta’s protections. From then on, handling is your job.

Exports are valuable. They allow analysis in spreadsheets, sharing with auditors and managers, and long-term evidence. But an export of identity data is a list of real people: names, email addresses, applications, sign-in times, and sometimes network locations. This is personal information, and in some reports it may reveal which sensitive systems a person uses. A careless export can become a privacy incident.

The life of an exported file

Rules for handling exports

Reports reveal who does what across the organization. Limit who may view them, and what they may do.

Reports contain sensitive information. A person who can see which applications every employee uses, and when, could misuse that knowledge. Okta controls access through administrator roles. Some roles can change settings. Others can only look. A dedicated reporting role exists so that people who need insight, such as auditors and analysts, do not need broad power to change the system.

Principles for assigning access

Follow a single request from idea to evidence, and see what data moves where.

What data moves where

Notice that the sensitive data exists in six different places by the end. Each copy multiplies the number of places to protect, which is why the earlier chapter urged exporting the minimum and deleting what you no longer need.

A report that changes nothing is a waste of time. Build a loop that turns findings into fixes.

flowchart TD
  Q["Ask a clear question"] --> R["Choose the right report and time range"]
  R --> F["Review findings and spot anomalies"]
  F --> D{"Is action needed?"}
  D -->|"Yes"| A["Create a ticket and fix the issue"]
  D -->|"No"| N["Record the result as evidence"]
  A --> V["Run the report again to verify the fix"]
  V --> N
    

The six steps

Making the loop a habit

The best reporting programs are boring. They run on a calendar. Weekly, someone glances at sign-in and failure trends. Monthly, someone reviews multi-factor coverage and lifecycle checks. Quarterly, someone compares assignments with usage for sensitive applications and reviews administrator roles. Annually, someone gathers the evidence pack for the audit. Each task is small, and together they keep the organization honest.

Auditors do not want promises. They want dated proof. Reports are the raw material of that proof.

Security and compliance frameworks, such as SOC 2 and ISO 27001, along with financial control regimes, commonly expect organizations to show that access is granted appropriately, reviewed regularly, and removed promptly, and that strong authentication is in use. Each framework phrases its requirements differently, but the evidence looks similar: dated records that show a control worked during the audit period.

What an evidence pack usually contains

How to build it without panic

Using reports to keep access lean: removing what is no longer needed before it becomes a risk.

Access tends to grow quietly. People change teams and keep old permissions. Projects end and the applications remain assigned. Temporary access becomes permanent because nobody remembers to remove it. Security teams call this access creep. The cure is a regular access review, in which someone examines who has access to what and confirms that each assignment is still justified.

A simple review process using reports

Signals that deserve extra attention

Built-in reports cover common needs. When yours are not common, other tools take over.

Built-in reports have natural limits. They have fixed shapes, so you cannot easily add a column you invented. They are mostly run on demand, so scheduling takes extra effort. Their retention follows Okta’s rules, not yours. When you hit those limits, Okta offers several ways to go further.

flowchart LR
  OKTA["Okta Org"] --> BUILTIN["Built-in Reports for quick answers"]
  OKTA --> LOGAPI["System Log API for custom queries"]
  OKTA --> STREAM["Log Streaming to long term storage"]
  OKTA --> WF["Okta Workflows for scheduled summaries"]
  STREAM --> SIEM["SIEM and Dashboards"]
  LOGAPI --> WH["Data Warehouse"]
  WF --> MAIL["Email or Chat Summaries"]
    

Choosing the next tool

When to graduate from built-in reports

Reports reveal who does what and who can reach which systems. That knowledge is valuable to attackers, too.

It is easy to see reports as harmless summaries. In truth, they are a map of your organization’s access and behavior. An attacker who obtains reports can learn which applications matter, who holds powerful roles, when people usually sign in, and where controls are weak. Protecting reports and the paths to them is part of protecting the organization.

Privacy matters too

Reports describe the behavior of real employees. Depending on where you operate, privacy laws and agreements may limit how that data may be collected, used, and retained. Be clear about the purpose of each report, share only with those who need it, and keep it no longer than necessary. A policy that says what reports are used for, and what they are never used for, protects both staff and the organization.

Defense in layers

Protect the accounts that can see reports, with strong authentication. Limit who can export. Store exports in controlled places. Log access. Review roles regularly. And educate staff about the sensitivity of the data. Each layer reduces the chance that a report becomes the first step of an attack or a privacy incident.

Reports watch the identity system. Someone must also watch the reports: who runs them, what they find, and whether anything changes.

A reporting program can fail quietly. Reviews stop happening. Exports pile up unread. Findings are noted and never fixed. The program needs its own measures, so that its health can be seen at a glance.

Metrics for the program

Watching who uses reports

Okta’s System Log records administrative activity, which may include who accessed reports and exports, depending on the event types in your release. Search the log for such activity and decide which events deserve alerts. A sudden series of large exports by an administrator who rarely does that is worth a conversation. So is an administrator accessing reports outside normal working hours from an unfamiliar location.

Reliable shapes that many successful reporting programs share.

How the patterns fit together

Question-first reporting keeps effort focused. The calendar keeps it regular. Paired reports give a complete picture. The evidence repository turns routine work into audit readiness. Streaming extends reach beyond built-in limits. Tickets turn findings into fixes. Narrow roles protect the data that makes all of this possible. Together they make reporting a habit rather than a fire drill.

Mistakes seen again and again, so you can skip them.

Every visibility tool buys something and costs something. Here is the honest ledger for built-in Okta reports.

Trade-offs to think through

Convenience versus flexibility. Built-in reports are quick but fixed. APIs and streaming are flexible but need engineering time. Start with the built-in reports and graduate when they stop fitting.

Detail versus privacy. More detail helps investigations but exposes more about people. Export only what the purpose needs.

Frequency versus effort. Weekly reviews catch problems sooner but cost more attention. Match frequency to the risk of what is being reviewed.

Reports versus alerts. Reports suit review and evidence. Alerts suit urgent events. A healthy program uses both, with each for its proper job.

Manual versus automated. Manual review is simple to start and error-prone at scale. Automation takes effort to build and pays back over time.

A checklist to read before every review and every audit.

Best practices

• Start with a question. Write it down before you open any report.
• Match the report family to the question, and use the System Log for individual investigations.
• Record the settings. Always note the report name, time range, and filters.
• Compare with baselines and similar earlier periods, not only with zero.
• Pair assignment and usage reports for sensitive applications.
• Run reports on a calendar and keep dated evidence all year.
• Export the minimum, store exports in controlled places, and delete them on schedule.
• Use narrow roles for report viewers, with strong authentication, and review role holders regularly.
• Turn findings into tickets with owners and due dates, and verify fixes with follow-up reports.
• Archive beyond retention through scheduled exports or log streaming.
• Pair reports with real-time alerts for urgent security events.
• Review the program itself each quarter, and retire reports nobody uses.
• Verify current behavior in your own console, since names and options change.

Common mistakes

Six stories showing reports at work. These are illustrative teaching designs, not descriptions of any named company’s real setup.

Most report trouble falls into a few families. A calm checklist solves most of it.

A simple troubleshooting routine

Short answers to the questions that come up most often.

If you remember nothing else, remember the box below.

Okta reports turn a flood of identity activity into answers that managers, auditors, and security teams can use. They help you see who signs in, how strongly, who has access to what, whether leavers really left, and whether anything suspicious is happening. But a report is only a starting point. Its value depends on a clear question, careful reading, safe handling of exports, and a habit of turning findings into fixes. Used regularly and protected properly, reports make audits calmer and identity risk smaller. Used carelessly, they become unread files and sensitive leaks.