diff --git a/docs/auth/index.md b/docs/auth/index.md
index 0efbbcef21..ecef22b612 100644
--- a/docs/auth/index.md
+++ b/docs/auth/index.md
@@ -10,6 +10,13 @@ configure Backstage to have any number of authentication providers, but only
 one of these will typically be used for sign-in, with the rest being used to provide
 access to external resources.
 
+> NOTE: Identity management and the Sign-In page in Backstage is NOT a method for blocking
+> access for unauthorized users. The identity system only serves to provide a personalized
+> experience and access to a Backstage Identity Token, which can be passed to backend plugins.
+> This also means that your Backstage backend APIs are by default unauthenticated.
+> Thus, if your Backstage instance is exposed to the Internet, anyone can access
+> information in the Backstage. You can learn more [here](../overview/threat-model.md#integrator-responsibilities).
+
 ## Built-in Authentication Providers
 
 Backstage comes with many common authentication providers in the core library:
@@ -60,13 +67,6 @@ the local `auth.environment` setting will be selected.
 
 ## Sign-In Configuration
 
-> NOTE: Identity management and the `SignInPage` in Backstage is NOT a method
-> for blocking access for unauthorized users, that either requires additional
-> backend implementation or a separate service like Google's Identity-Aware
-> Proxy. The identity system only serves to provide a personalized experience
-> and access to a Backstage Identity Token, which can be passed to backend
-> plugins.
-
 Using an authentication provider for sign-in is something you need to configure
 both in the frontend app, as well as the `auth` backend plugin. For information
 on how to configure the backend app, see [Sign-in Identities and Resolvers](./identity-resolver.md).