Zero trust is not a product you buy — it is the implementation of least privilege throughout an entire ecosystem. Every vendor now claims to be “zero trust,” but without understanding where each tool fits within the NIST 800-207 reference architecture, organizations end up with expensive shelfware rather than actual security improvement. Vincent Romney, Head of Global Security Architecture at Nu Skin Enterprises, has led the design and implementation of information security programs across large enterprises. In this episode, he breaks down where to start the zero trust journey, why identity is the core feeder to zero trust (but not zero trust itself), and how to protect sensitive data with policy-driven access control.
You can read the complete transcript of the episode here >
Where should organizations start their zero trust journey?
The core principle behind zero trust is deep perimeterization — shrinking implicit trust zones down to the narrowest possible scope with authentication throughout. But you cannot do that without knowing what you have.
- CIS Benchmarks 1 and 2 are the starting point. These are asset inventory — hardware and software. Without an accurate assessment of what exists in your environment, zero trust remains theoretical. You need to know your infrastructure, your application environment, and where current trust perimeters exist.
- Understand your current trust boundaries. Most organizations have wide implicit trust zones. The zero trust journey is simply shrinking those down by inserting authentication and authorization checks at every boundary crossing.
- Evaluate through the lens of NIST 800-207. This is the foundational document for zero trust. When vendors claim “zero trust,” evaluate where their tool fits within the 800-207 reference architecture. If they cannot point to a specific function (policy engine, policy administrator, policy enforcement point), their claim may be marketing.
- Leverage what you already own. Most organizations — especially those in the Office 365 ecosystem — have identity providers, conditional access, and role-based controls they are not fully leveraging. Turn on existing capabilities before buying new tools.
For cost-sensitive organizations, the message is clear: cloud asset management is not just a nice-to-have — it is the prerequisite for any meaningful security architecture.
How does identity feed into zero trust?
Vince makes an important distinction: identity feeds the zero trust architecture — it is not zero trust in itself. Within the NIST 800-207 model:
- Policy Engine: Drives the policies that govern access decisions.
- Policy Administrator: Makes the actual decision based on policy engine rules.
- Policy Enforcement Point: Executes the decision (allow or deny).
Together, the policy engine and administrator form the policy decision point, which lives in the control plane. Identity is what gets evaluated by this system.
The practical implementation:
- Start with true least privilege. Not the watered-down version where everyone gets “standard user” access — actual role decomposition where each identity assumes only the roles required for their specific function.
- Define policies before enforcement. You need to know what access patterns are legitimate before you can block illegitimate ones. This requires understanding data use cases, role definitions, and workflow requirements.
- Even compromised identities get blocked in zero trust. If an attacker compromises an identity on the perimeter but their subsequent behavior does not match defined use cases and policies, the system blocks them at the next trust boundary. This is the value of deep perimeterization — one compromised credential does not equal full access.
This role-based, policy-enforced model is what separates modern IAM from simple authentication.
What is the right approach to MFA?
Not all MFA is created equally. Vince walks through the hierarchy:
- SMS-based MFA: Easily circumvented through SIM swapping and SS7 attacks. Better than nothing, but provides low confidence.
- Email-based MFA: Compromised email means compromised second factor. Similarly low confidence.
- App-based authenticators (e.g., Microsoft Authenticator): Significantly better. The phone is “something you have,” the code or biometric approval adds a verification layer. Still not infallible but a major step up.
- Hardware tokens (e.g., YubiKey): The strongest option available. Major organizations that have deployed hardware tokens across their workforce report very few successful credential-based attacks. The physical possession requirement makes remote compromise extremely difficult.
The practical guidance: if you are not using any MFA, start immediately — even SMS is better than nothing. But move toward hardware tokens as quickly as budget and logistics allow. The organizations that have eliminated credential attacks did it through universal hardware token deployment, not through incremental MFA improvements.
How should sensitive data like healthcare records be protected?
For organizations under HIPAA compliance or similar regulatory frameworks, data protection requires both security and demonstrability:
- Define data use cases precisely. What is a patient record required to do? Who needs access, under what circumstances, for what purpose? Limit access to exactly those use cases and disallow everything else.
- Build policies around use cases, not users. A role is assigned specific use cases. An identity assumes a role. Access is granted based on whether the use case matches policy — not based on who the person is.
- Log everything for compliance demonstration. HIPAA requires demonstrating that controls are effective. Every access event, every policy decision, every authentication — all must be logged and auditable.
- Security first, compliance second. Vince’s strong opinion: approach security requirements first, then demonstrate that security to match compliance. Organizations that chase compliance first often find they have checked boxes without actually securing anything.
The zero trust model applied to healthcare data means that even if an attacker compromises a legitimate identity, they cannot reach patient records unless their behavior matches the exact use cases defined in policy — and those use cases are re-verified at every trust boundary, not just at the perimeter.
