TL;DR: ANZ enterprises are using customer identity data to improve customer experiences and support zero trust priorities, according to Ping Identity’s survey report on how CIOs are leveraging customer data. The implication for IAM teams is that customer identity programmes now sit between personalisation, risk, and governance, not just login and profile management.
At a glance
What this is: This is a survey report about how ANZ enterprises use customer data through identity to improve experience and support security priorities.
Why it matters: It matters to IAM practitioners because customer identity governance increasingly affects both experience design and security controls, especially where identity data is shared across access, analytics, and zero trust initiatives.
👉 Read Ping Identity's survey report on how CIOs are leveraging customer data
Context
Customer identity and access management is no longer just about sign-in. In practice, it now determines how organisations use identity data to shape customer journeys, risk decisions, and trust controls across digital channels.
This report focuses on ANZ enterprises and how they are leveraging customer data through identity. That makes it relevant to practitioners responsible for CIAM, data governance, and the security controls that govern customer-facing identity flows.
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 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.
Q: What do teams get wrong about personalisation and identity verification?
A: Teams often treat customer history, device behaviour, or engagement data as proof of identity. Those signals can improve experience, but they do not confirm who is actually present. Identity verification requires explicit evidence and policy, especially before sensitive actions.
Q: Who should own customer identity governance when experience and security collide?
A: CIAM needs shared ownership across security, product, and customer experience teams because the impact spans access, conversion, and privacy. Security can define assurance requirements, but product and CX must help shape the journey so controls do not destroy trust in the process.
Technical breakdown
How customer identity data supports experience and trust decisions
Customer identity data can include profile attributes, authentication signals, consent state, and behavioural context. Used well, it helps organisations reduce friction, personalise journeys, and make access decisions that are more responsive to risk. Used poorly, the same data becomes fragmented across systems, creating inconsistent policy enforcement and a broader privacy exposure surface. For IAM teams, the technical issue is not simply data collection. It is whether identity context is available at the point of decision and governed consistently across channels.
Practical implication: align customer identity data sources with the policies that consume them, rather than treating experience and security as separate systems.
Why zero trust depends on trustworthy customer identity context
Zero trust in customer environments depends on identity evidence that is current, relevant, and bounded to the session or transaction. That means customer profiles, device signals, and authentication outcomes must be treated as governed inputs, not informal metadata. When those signals are stale or incomplete, access decisions become guesswork and trust boundaries weaken. The technical challenge is not only authentication strength, but the integrity of the identity data used to drive conditional access and assurance decisions.
Practical implication: validate the freshness and provenance of customer identity signals before using them in zero trust policy.
NHI Mgmt Group analysis
Customer identity data has become a governance asset, not just a personalisation input. Once identity information feeds both experience design and access decisions, the governance burden changes. The same profile data that improves conversion can also expand exposure if collection, retention, and policy use are not tightly bounded. Practitioners should treat customer identity data as a controlled security input, not a marketing by-product.
CIAM and zero trust now intersect at the policy layer. The article points to a familiar enterprise shift: customer data is being used to drive trust decisions, not merely user journeys. That creates a need for clearer rules about which identity signals are authoritative, which are advisory, and which should never influence access. IAM teams should expect the boundary between customer experience and security architecture to keep narrowing.
The named concept here is identity trust enrichment. This is the practice of combining customer data with identity signals to increase assurance, reduce friction, or personalise decisions. The risk is that enrichment often outruns governance, leaving teams unable to explain why a decision was made or which data source carried authority. Practitioners need to treat enrichment pipelines as policy-bearing systems.
ANZ customer identity programmes expose the same control tension seen across NHI and human IAM. More data can improve decisions, but only if it is governed as carefully as credentials or access entitlements. The lesson for identity teams is that data volume does not equal identity assurance, and more context can create more ambiguity if ownership is unclear. Teams should define which sources are allowed to change trust decisions.
From our research:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- For identity teams building a broader governance baseline, the NHI Lifecycle Management Guide helps connect provisioning, rotation, and offboarding into one operating model.
What this signals
Customer identity programmes are moving closer to the control plane of the enterprise, which means data governance and IAM can no longer be separated cleanly. Once profile and assurance signals shape access decisions, the quality of those inputs becomes a security issue as much as a customer experience issue.
Identity trust enrichment: the more organisations combine customer data with identity signals, the more they need policy boundaries that explain which inputs are authoritative. Without that discipline, experience optimisation can quietly become an access control problem.
For teams formalising their broader identity programme, the governance challenge is similar to the one described in Top 10 NHI Issues: scale increases faster than control unless ownership, lifecycle, and decision rights are explicit.
For practitioners
- Map customer identity data flows end to end Document where customer attributes, authentication results, consent state, and behavioural signals are collected, stored, and consumed. Identify every system that uses those signals for access, personalization, or fraud reduction, then assign a control owner for each handoff.
- Separate authoritative signals from advisory signals Define which customer identity inputs can change access decisions and which can only inform them. Use policy documentation to prevent low-confidence signals from silently becoming enforcement inputs across channels.
- Review retention and reuse rules for identity data Confirm that customer identity attributes used in trust decisions are retained only as long as needed and are not repurposed without approval. This is especially important when analytics teams and IAM teams share the same data sources.
- Align CIAM controls with zero trust policy design Make sure conditional access rules, step-up authentication, and profile-based decisions use governed identity data with known provenance. The decision logic should be auditable, especially when customer journeys span multiple applications.
Key takeaways
- Customer identity data is becoming a governed security input, not just a personalisation asset.
- When identity signals influence trust decisions, provenance and policy clarity matter more than data volume.
- IAM teams should align CIAM, analytics, and zero trust controls around auditable identity data use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Customer identity data is being used to drive access decisions and trust policy. |
| NIST SP 800-63 | SP 800-63C | Federation and identity assertion handling are central to customer identity governance. |
| NIST Zero Trust (SP 800-207) | Zero trust depends on trustworthy identity context for conditional decisions. | |
| ISO/IEC 27001:2022 | A.5.15 | Access control requirements apply when customer identity data drives policy decisions. |
Align customer identity signals with zero trust policy design and audit the decision inputs.
Key terms
- Customer Identity: Customer identity is the authentication and account layer used for app users, sign-in, federation, and profile management. It is built to manage user access into applications, not to mediate privileged infrastructure activity or deep protocol-level control.
- Identity Trust Enrichment: The practice of combining multiple identity and behavioural signals to improve confidence in a decision. It can reduce friction and improve assurance, but only when the contributing data sources are authoritative, current, and governed so that the resulting decision can be explained later.
- Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
What's in the full report
Ping Identity's full survey report covers the operational detail this post intentionally leaves for the source:
- Survey findings on how ANZ organisations are actually using customer identity data across experience and security use cases
- Breakdowns of the survey questions and response context that support the report's conclusions
- Additional customer identity and zero trust use cases discussed in the report beyond the high-level governance view
- The complete framing of CIO priorities, including how respondents think about data use and identity-driven trust decisions
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.
Published by the NHIMG editorial team on July 28, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org