diff --git a/django/views/csrf.py b/django/views/csrf.py
index f22f3b25ac..493e112fbe 100644
--- a/django/views/csrf.py
+++ b/django/views/csrf.py
@@ -78,6 +78,9 @@ CSRF_FAILURE_TEMPLATE = """
     <code>csrf_protect</code> on any views that use the <code>csrf_token</code>
     template tag, as well as those that accept the POST data.</li>
 
+    <li>The form has a valid CSRF token. After logging in in another browser
+    tab or hitting the back button after a login, you may need to reload the
+    page with the form, because the token is rotated after a login.</li>
   </ul>
 
   <p>You're seeing the help section of this page because you have <code>DEBUG =
diff --git a/docs/ref/csrf.txt b/docs/ref/csrf.txt
index ca94b21552..e5d32b27b3 100644
--- a/docs/ref/csrf.txt
+++ b/docs/ref/csrf.txt
@@ -227,6 +227,9 @@ The CSRF protection is based on the following things:
    every response that has called ``django.middleware.csrf.get_token()``
    (the function used internally to retrieve the CSRF token).
 
+   For security reasons, the value of the CSRF cookie is changed each time a
+   user logs in.
+
 2. A hidden form field with the name 'csrfmiddlewaretoken' present in all
    outgoing POST forms.  The value of this field is the value of the CSRF
    cookie.
@@ -505,3 +508,11 @@ because it invalidates all previous forms. Most users would be very unhappy to
 find that opening a new tab on your site has invalidated the form they had
 just spent time filling out in another tab or that a form they accessed via
 the back button could not be filled out.
+
+Why might a user encounter a CSRF validation failure after logging in?
+----------------------------------------------------------------------
+
+For security reasons, CSRF tokens are rotated each time a user logs in. Any
+page with a form generated before a login will have an old, invalid CSRF token
+and need to be reloaded. This might happen if a user uses the back button after
+a login or if they log in in a different browser tab.