Protecting PII in Fabric

This is a common challenge in modern data platforms, and you're correct that RLS, CLS, and Dynamic Data Masking are not sufficient if your requirement is that Data Engineers must never be able to view the PII in plaintext.

The recommended approach is to use encryption/tokenization before the data reaches Fabric, combined with strict separation of duties.

A typical architecture looks like this:

• Source System / Ingestion

  • Encrypt or tokenize sensitive PII before it lands in Fabric (using Azure Key Vault-managed keys or an external tokenization service).

• Fabric Lakehouse / Warehouse

  • Store only the encrypted or tokenized values.

  • Data Engineers work with encrypted data and never have access to the decryption keys.

• Power BI / Authorized Applications

  • Only trusted services or applications with access to the encryption keys decrypt the values for authorized users.

If you need Power BI users to see the original PII, the decryption should occur in a controlled layer outside the reach of Data Engineers. This ensures the keys are never exposed within Fabric notebooks, SQL scripts, or workspace permissions.

At present, Fabric provides features such as:

• Row-Level Security (RLS)

• Column-Level Security (CLS)

• Sensitivity labels

• Microsoft Purview integration

• Customer-managed keys (CMK) for encryption at rest

However, these features do not prevent privileged data engineers from seeing plaintext if the data is already decrypted within Fabric.

If you're comparing with Snowflake, features such as tag-based masking policies, row access policies, and external tokenization integrations provide finer-grained control. Fabric is evolving rapidly, but an equivalent policy-based, role-aware decryption capability is not generally available today.

For highly regulated environments (healthcare, finance, government), organizations typically implement:

• Tokenization instead of reversible encryption where possible.

• Separation of duties (engineers manage pipelines, security teams manage keys).

• Azure Key Vault or an external HSM for key management.

• Microsoft Purview for data classification, governance, and auditing.

• Just-in-time access and comprehensive audit logging.

If your requirement is that no Fabric administrator or Data Engineer can ever view plaintext PII, then the safest pattern today is to keep PII encrypted/tokenized throughout Fabric and perform decryption only in a tightly controlled application or trusted service that has access to the encryption keys.

For more information:

• Microsoft Fabric security overview: https://learn.microsoft.com/fabric/security/security-overview

• Microsoft Purview information protection: https://learn.microsoft.com/purview/

• Azure Key Vault: https://learn.microsoft.com/azure/key-vault/general/overview

💡 Helpful? Give a Kudos 👍 — keep the community growing.

✅ Solved your issue? Mark this as the Accepted Solution ✔️

Best regards, Prince Singh | Data Science & Microsoft Fabric Enthusiast

Ira_27 

I don't think Fabric currently providesdynamic masking policies that prevent privileged engineering roles from seeing sensitive values while still allowing authorized consumers to access them.

For highly sensitive PII, the common pattern is:

• Encrypt or tokenize PII before it lands in Fabric
• Expose only masked, tokenized, or anonymized values to Data Engineers (but restrict access to the decryption process to a very limited set of authorized users or applications)
  
  

RLS, CLS, and Dynamic Data Masking help control consumer access, but they do not prevent Fabric administrators or users with sufficient data access from potentially viewing the underlying data in Fabric.
If the requirement is that Data Engineers must never be able to see PII in plaintext, then the safest approach is to ensure plaintext PII never enters Fabric in the first place. Fabric should only receive encrypted or tokenized values, with decryption performed outside Fabric or at a tightly controlled application layer.
scenario, although Microsoft continues to invest in governance and security capabilities.

Appreciate if you can "Kudos" and/or "Accept as Solution" if this answered your query.

Ira_27 
RLS and CLS controls and masking is not sufficient in this case

Best Industry Practice
Keep PII in a highly restiricte area database ( for example Azure SQL)

Fabric must contain only 
1-Customer ID
2-Hash
3-Token
4-Business Attributes

Only sperate application retrieves PII when needed.Always keep PII data outside of analytics platform.

If this helps, ✓ Mark as Kudos | Help Others

Hi Ira_27 

One of the ways I could think you might be able to do this is to keep a workspace that the data engineers not have access to. Then create views which will use dynamic data masking to mask the data when queried by a SQL endpoint. Then get the data engineers to use the views to query the data so that they can then not see the actual underlying data because it will be masked by the view. And then finally when this is deployed to your production workspace. The views will be shown to users who can see the data that is not dynamically masked.

Do not give Data Engineers access to PROD sensitive / secure data. Only service principals should have permissions to those datasets. If not done already you should seperate your prod workspace and DEV workspace. Build occurs on DEV and once moved to PROD only the required folks should have limited access to the secure data. 

Dynamic Masking is an option but does not provide the best security.