diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc
index fcd9b59521..5407253cd2 100644
--- a/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc
+++ b/docs/manual/src/docs/asciidoc/_includes/servlet/architecture/technical-overview.adoc
@@ -90,22 +90,6 @@ In many cases it makes more sense to <<core-services-authentication-manager,impl
 ====
 
 
-[[tech-granted-authority]]
-==== GrantedAuthority
-Besides the principal, another important method provided by `Authentication` is `getAuthorities()`.
-This method provides an array of `GrantedAuthority` objects.
-A `GrantedAuthority` is, not surprisingly, an authority that is granted to the principal.
-Such authorities are usually "roles", such as `ROLE_ADMINISTRATOR` or `ROLE_HR_SUPERVISOR`.
-These roles are later on configured for web authorization, method authorization and domain object authorization.
-Other parts of Spring Security are capable of interpreting these authorities, and expect them to be present.
-`GrantedAuthority` objects are usually loaded by the `UserDetailsService`.
-
-Usually the `GrantedAuthority` objects are application-wide permissions.
-They are not specific to a given domain object.
-Thus, you wouldn't likely have a `GrantedAuthority` to represent a permission to `Employee` object number 54, because if there are thousands of such authorities you would quickly run out of memory (or, at the very least, cause the application to take a long time to authenticate a user).
-Of course, Spring Security is expressly designed to handle this common requirement, but you'd instead use the project's domain object security capabilities for this purpose.
-
-
 ==== Summary
 Just to recap, the major building blocks of Spring Security that we've seen so far are:
 
diff --git a/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/granted-authority.adoc b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/granted-authority.adoc
new file mode 100644
index 0000000000..fea2fb24bc
--- /dev/null
+++ b/docs/manual/src/docs/asciidoc/_includes/servlet/authentication/architecture/granted-authority.adoc
@@ -0,0 +1,14 @@
+[[servlet-authentication-granted-authority]]
+= GrantedAuthority
+Besides the principal, another important method provided by `Authentication` is `getAuthorities()`.
+This method provides a `Collection` of `GrantedAuthority` objects.
+A `GrantedAuthority` is, not surprisingly, an authority that is granted to the principal.
+Such authorities are usually "roles", such as `ROLE_ADMINISTRATOR` or `ROLE_HR_SUPERVISOR`.
+These roles are later on configured for web authorization, method authorization and domain object authorization.
+Other parts of Spring Security are capable of interpreting these authorities, and expect them to be present.
+`GrantedAuthority` objects are usually loaded by the `UserDetailsService`.
+
+Usually the `GrantedAuthority` objects are application-wide permissions.
+They are not specific to a given domain object.
+Thus, you wouldn't likely have a `GrantedAuthority` to represent a permission to `Employee` object number 54, because if there are thousands of such authorities you would quickly run out of memory (or, at the very least, cause the application to take a long time to authenticate a user).
+Of course, Spring Security is expressly designed to handle this common requirement, but you'd instead use the project's domain object security capabilities for this purpose.