What NSS and LSS feeds enable in CentaurNexus

OneAPI and log feeds answer different questions

The official Zscaler OneAPI remains the central interface for supported configuration and status data as well as controlled reads and writes. Log feeds add observed access, rule activity and sessions to that current state. Together they provide the context required for many historical and operational analyses.

Three feed types with distinct roles

Where the feeds create practical product value

• Help desk and end users: User Support Center and Unified Support Center combine session state, connector context and blocked websites with the available user, device and policy picture. Requests from the browser and self-service therefore reach the help desk with stronger initial context.
• Security: Reports show blocked access, trends, common categories, Page Risk distributions, Shadow IT, geographic and other available risk signals.
• Administration and second level: Bandwidth can be analysed by application, location, user and time. Firewall rule activity supports the assessment of unused or noteworthy rules.
• Management and MSPs: Aggregated reports and tenant-bound analysis improve comparability without mixing customer contexts.

Review changes against observed usage

For supported change and approval workflows, CentaurNexus can evaluate past access within the available history. The retrospective can show how often a target or category occurred, which decisions were actually taken and how many users were affected. A change preview can therefore draw on observed usage as well as the current rule set.

Source, data age and coverage are part of the result

A value without source state can easily be misread. CentaurNexus therefore carries source, status, data age and coverage with the result. Feed gaps and stale data remain visible. A missing feed is not presented as a confirmed zero.

Earlier onboarding creates a comparison base sooner

History starts with reliable feed connection. Access and sessions from before that point cannot be reconstructed later. Some analyses provide initial results immediately, while recurring patterns and rule activity become more meaningful as history grows.

This always applies within the retention that was actually agreed. Purpose-bound product projections follow their defined data classes. Additional or different NSS and LSS retention is not promised broadly and must be defined for the tenant and operating scope.

Connect NSS and LSS alongside existing data paths

Where the Zscaler deployment permits it, a dedicated feed can supply CentaurNexus alongside the existing SIEM connection. CentaurNexus uses NSS and LSS as product sources for user context, reporting, rule assessment and change retrospectives.

Feed quality means more than “connected”

A green connection does not prove that a feed is complete and current enough for a particular analysis. Relevant indicators include the latest event time, expected and observed volume, parser state, tenant assignment and coverage of the period under review. CentaurNexus carries these indicators with the result so that incomplete data does not look like a complete finding.

Format changes also require visible handling. If fields are missing or their meaning no longer matches the expected contract, the platform must not derive an apparently precise statement from them. The affected part of the analysis receives a traceable source status, while independently available functions can continue to operate.

A help desk example

A user reports that a private application worked in the morning but stopped later in the day. OneAPI can provide current configuration and status context. ZPA LSS adds observed sessions and available connector context. NSS web or NSS firewall can contribute further signals when the workflow also touches web or firewall paths.

The help desk therefore sees more than a snapshot. It can relate the time of the issue to the history that is actually available and hand the case to second level with a clearer finding. The conclusion remains bound to the visible coverage.

An administration and security example

When an older firewall rule is reviewed, its name is not enough. NSS firewall can show whether and when it was used within the available history, which services were involved and whether allowed or blocked sessions were observed. This evidence supports a human decision about the next review step.

Security teams can also aggregate web access, categories, block decisions and available risk signals over time. The resulting report remains distinct from raw-log search. It answers a defined operational question and identifies the source used.

Onboarding starts the data curve

For every intended use case, teams should establish which feed is required, which fields actually arrive and how long the agreed history remains available. An earlier start builds that comparison base sooner. It cannot reconstruct activity from before onboarding and does not expand the contractually defined retention.

In practical terms, early connection lets teams evaluate recurring usage, seasonal patterns and rule activity over a longer period sooner. Feed planning therefore belongs at the beginning of onboarding rather than at the end of a later investigation.

Questions that improve with growing history

A longer, consistent data base makes comparisons stronger. Teams can assess whether unusual access was isolated, whether an application is used at recurring times or whether a rule has shown no observed activity across several operating cycles. History provides context but does not make the decision automatically.

Management and MSPs can use this context for traceable trend reports. A comparison should include only tenants, periods and sources whose coverage is known. Different feed quality must not be hidden behind an apparently uniform metric.

Data minimisation remains part of the product contract

The fact that a feed can provide many fields does not mean that every raw item must be stored permanently for every function. CentaurNexus uses purpose-bound projections for supported analyses. Data class, tenant assignment and agreed retention govern their life cycle.

This separation makes domain review easier. Customers can understand which analysis needs which source and how long the relevant context remains available. Additional requirements are agreed explicitly rather than inferred silently from a technical feed capability.