Customer data, identity, and zero trust in ANZ enterprises

At a glance

What this is: Ping Identity’s survey report says ANZ enterprises are using customer identity data to improve customer experience while supporting zero trust goals.

Why it matters: For IAM teams, this shows CIAM is no longer just an authentication layer because customer identity data now affects governance, access boundaries, and privacy decisions.

Context

This survey report is about how CIOs in ANZ are using customer identity data, not just customer login flows, to shape experience and trust decisions. The primary governance issue is how customer identity information is collected, reused, and controlled across identity, risk, and privacy functions.

CIAM programmes increasingly sit between personalisation and security policy. That changes the practitioner question from whether identity data exists to whether its use is governed well enough to support zero trust without overexposing customer profiles or expanding access scope.

Key questions

Q: How should organisations govern customer identity data for personalization?

A: Organisations should treat customer identity data like governed source material, not campaign input. That means reconciling duplicates, validating attributes, separating consented data from inferred data, and retiring stale records before they affect segmentation. Personalization fails when identity hygiene is weak because the system optimizes around the wrong person or the wrong preference.

Q: Why can zero trust fail in CIAM programmes even when authentication is strong?

A: Strong authentication does not stop over-sharing of customer attributes. Zero trust fails when profile data, support access, and analytics workflows can all read the same identity data without purpose limits, because the trust boundary shifts from the session to the data itself. Practitioners need access control for attributes, not only for logins.

Q: What are the signs that customer identity governance is too broad?

A: Warning signs include the same customer attributes appearing in multiple downstream systems, inconsistent consent handling, and support or marketing teams using identity data that was collected for authentication. If nobody can explain which attributes are needed for each workflow, the CIAM programme has become a data-sharing platform rather than a governed identity control.

Q: Why does customer identity matter to zero trust programmes?

A: Customer identity matters because zero trust depends on current, trustworthy context at the moment of decision. If profile data, device signals, or authentication outcomes are stale or inconsistent, policy becomes less reliable. Teams need governed identity signals that can support conditional access without creating hidden assumptions.

Technical breakdown

Customer identity data as a trust input

Customer identity and access management (CIAM) often starts with authentication, but this report points to a broader pattern: customer data is being used to influence trust decisions. That includes profile data, behavioural signals, and relationship context that inform how much friction to apply, what access to grant, and when to challenge a session. The technical issue is not just identity proofing. It is how identity data is consumed downstream by policy engines, risk scoring, and customer-facing journeys without creating uncontrolled reuse.

Practical implication: map every customer identity data source to the trust decision it influences and restrict reuse to explicit policy purposes.

Zero trust in customer identity programmes

Zero trust is often discussed as a network or workforce architecture, but in CIAM it becomes a data and decision problem. If customer identity attributes are over-shared across channels, teams lose the ability to apply least-privilege access to profile data, support tooling, and downstream analytics. In practice, zero trust for customer identity depends on limiting who can query which attributes, under what conditions, and for what purpose. That is a governance layer as much as an access-control layer.

Practical implication: treat customer attributes as governed assets and apply least-privilege access to every consumer of identity data.

Why identity data and privacy controls converge

When customer identity data is used to improve experience, it tends to spread across marketing, service, fraud, and security workflows. Each additional use case expands the governance surface, especially where consent, retention, and data minimisation obligations apply. The technical challenge is that the same attribute can be legitimate in one workflow and excessive in another. Without clear data lineage and policy enforcement, CIAM becomes an unbounded data-sharing layer rather than a controlled identity service.

Practical implication: define attribute-level governance rules so customer identity data cannot drift from authentication into unrelated processing without review.

NHI Mgmt Group analysis

Customer identity governance is now a cross-functional control plane, not a login function. When enterprises use customer data to drive experience and trust decisions, CIAM stops being a narrow access service and becomes a policy surface shared by security, privacy, and digital teams. That makes attribute scope, reuse, and entitlement boundaries the real control questions. Practitioners should govern customer identity data as a controlled input to business decisions, not as a passive profile store.

Zero trust becomes incomplete if customer identity data is over-shared. Zero trust depends on limiting what each system can see and do, yet customer identity programmes often distribute the same attributes into support, analytics, and personalisation flows. That creates access sprawl around data rather than around accounts. The practitioner conclusion is that least privilege must extend to customer attributes, not just to authenticated sessions.

Personalisation and governance now compete inside the same identity workflow. The more customer identity data is used to tailor journeys, the more pressure there is to expand data collection and reuse. That does not make the use case wrong, but it does mean identity teams must treat data minimisation, retention, and purpose limitation as design constraints. Practitioners need CIAM policies that preserve customer experience without turning convenience into uncontrolled data propagation.

Customer identity programmes expose a distinct governance gap: attribute reuse without explicit lifecycle control. Customer data is frequently collected once and then consumed many times across the enterprise. That assumption only works when every downstream use is visible, authorised, and reviewable. Practitioners should rethink customer identity lifecycle governance as a data-use problem, not just an account-management problem.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.

What this signals

Customer identity governance needs to move closer to policy enforcement. When the same customer attributes are reused across support, fraud, and personalisation, the real control point is no longer the login page. It is the policy layer that decides which consumer can read which attribute and for what purpose.

CIAM teams should expect privacy and zero trust to converge. The more customer data is used to shape trust decisions, the more identity teams will be asked to prove that data minimisation, consent handling, and least-privilege access are all working together.

For practitioners

• Define customer attribute purpose limits Document which customer identity attributes are allowed for authentication, risk scoring, support, marketing, and analytics, and block reuse outside those purposes.
• Apply least privilege to attribute consumers Restrict which applications and teams can read high-value identity attributes, especially where profile data can influence trust decisions or customer support workflows.
• Map data lineage across CIAM flows Trace where customer identity data originates, where it is enriched, and which systems consume it so governance teams can spot uncontrolled propagation.
• Review consent and retention controls Align retention periods and consent handling with each downstream identity use case so customer data does not persist longer or spread further than required.

Key takeaways

• Customer identity data is being used for both experience and security decisions, which makes CIAM a governance problem as well as an authentication problem.
• The core risk is over-sharing, because the same attributes can spread across support, analytics, and personalisation workflows without clear controls.
• Practitioners should tighten purpose limits, attribute-level access, and lifecycle governance so customer data supports zero trust without expanding exposure.

Key terms

• Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
• Column-level governance: Column-level governance is the control of access to specific data fields rather than entire tables or datasets. For AI agents, this is often the right control grain because it lets security teams limit sensitive data exposure without breaking analytics workflows or over-privileging the agent identity.
• Purpose limitation: The rule that data should be used only for the specific business purpose allowed by policy and context. In AI environments, this means a dataset may be technically accessible but still inappropriate for a given model, assistant, or agent if the use case exceeds the approved scope.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.