Advance your Data & AI career with 50 days of live learning, dataviz contests, hands-on challenges, study groups & certifications and more!
Get registeredGet Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now
Hello Fabric community. I'd like to pick your collective brain for this situation.
I am working on an initial Fabric implementation for the financial organization that follows CIS minimum standard framework and NIST where applicable. Under these frameworks they configure all Azure Key Vaults for private access only (in networking public access is diabled). I need to create a mirrored database from the on-premise SQL server using On-premise Data Gateway. For that, I need to configure a connection to the SQL Server using SQL authentication for which I must supply user name and password. I'd like to supply the password from the Key Vault which requires creating a Key Vault reference in Fabric. I can only create a Key Vault reference in Fabric if the Key Vault has public access enabled, otherwise the private connection between Fabric and Key Vault would fail. Such requirement for the public access to the Key Vault contradicts with the organization security framework. Are there any ways to mitigate this situation?
Solved! Go to Solution.
Hello @tayloramy @v-prasare, thank you for your support. While @tayloramy 's answers were infromative and helful, I, unfortunately, cannot accept them as a solution as my question uncovered an architectural limitation in the current state of Microsoft Fabric and the issue cannot be resolved directly. In the scenario I described, I have chosen not to use the Key Vault (as I usually did when I worked with Azure Data Factory or Azure Synapse) for storing credentials because from my assesment public Azure Key Vault presents a larger attack surface compared to storing credentials in the connections in Microsoft Fabric. Please consider this question closed unless there is more information on this topic that you could add for further considerations.
Hello @tayloramy @v-prasare, thank you for your support. While @tayloramy 's answers were infromative and helful, I, unfortunately, cannot accept them as a solution as my question uncovered an architectural limitation in the current state of Microsoft Fabric and the issue cannot be resolved directly. In the scenario I described, I have chosen not to use the Key Vault (as I usually did when I worked with Azure Data Factory or Azure Synapse) for storing credentials because from my assesment public Azure Key Vault presents a larger attack surface compared to storing credentials in the connections in Microsoft Fabric. Please consider this question closed unless there is more information on this topic that you could add for further considerations.
Hi @apturlov ,
Thank you for your thorough and well considered summary of the situation. You are correct this is not a configuration issue, but rather an architectural limitation in how Fabric currently handles Key Vault references. At this time, Fabric connections can only access Key Vaults with public access enabled, and private endpoint integration is not yet supported.
Your evaluation of the trade-offs between using a public Key Vault and storing credentials directly in Fabric connections is accurate. As @tayloramy noted, credentials in gateway-based connections are encrypted with the gateway recovery key, providing security at rest. Given these constraints, your decision to avoid Key Vault until private endpoint support becomes available is both reasonable and secure.
Microsoft recognizes the need for feature parity with services like Azure Synapse and Data Factory, which already support private endpoint Key Vault references. Monitoring Fabric release notes or the roadmap for future updates in this area is advisable.
Thank you again for sharing your detailed analysis it provides valuable insight for others encountering similar challenges.
Thank you,
Tejaswi.
Hi @apturlov,
We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.
Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support
Hi @apturlov,
We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.
@tayloramy ,Thanks for your prompt response
Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support
@tayloramy thanks for the answer and providing all related information sources. Appreciate the time you put into this. Unfortunately, this does not answer my question which was how to mitigate a conflict between the current state of Key Vault reference in Fabric and supplying a password for the on-premise database connection. Is it safe to supply a password directly in the connection configuration window when the Key Vault reference cannot be used due to the organization's policy restrictions? How does Fabric store the sensitive information like connection credentials?
Hi @apturlov,
The Key Vault reference feature in Fabric does currently require the vault to be reachable over its public endpoint, so if you're needing to use Key Vaults and can't enable the public endpoint, then there is no mitigation right now.
If your connection is on a gateway, the credentials will be encrypted using the gateway recovery key that was created when the gateway was installed. Change the recovery key for an on-premises data gateway | Microsoft Learn
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
Hi @apturlov,
You’ve run into a real limitation, not a misconfiguration. Today (Oct 9, 2025), Azure Key Vault references in Fabric require the vault to be reachable over its public endpoint. Private endpoints aren’t honored by the “Key Vault reference” feature yet, so a vault with “Public access: Disabled” can’t be added as a reference or used by those connections. Microsoft’s docs describe how to create Key Vault references but don’t (yet) include a private-endpoint path, and community threads confirm the current behavior. See: Configure Azure Key Vault references, Azure Key Vault Reference overview (Preview), and discussion noting the public-access requirement: r/MicrosoftFabric: Unable to create keyvault reference and Fabric Community: Azure Key Vault References. By contrast, Managed Private Endpoints (MPE) in Fabric do list Azure Key Vault as a supported target for managed VNET scenarios, but that networking path applies to workloads like notebooks/pipelines; the Key Vault reference feature used by Fabric connections doesn’t yet flow through MPE. See: Managed private endpoints overview and supported sources list: Create and use managed private endpoints.
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.
Check out the November 2025 Fabric update to learn about new features.
Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!
| User | Count |
|---|---|
| 14 | |
| 11 | |
| 5 | |
| 5 | |
| 4 |