diff --git a/library/ssl_tls.c b/library/ssl_tls.c
index 67cbdf4233..911664eb99 100644
--- a/library/ssl_tls.c
+++ b/library/ssl_tls.c
@@ -3777,6 +3777,7 @@ int mbedtls_ssl_read_record_layer( mbedtls_ssl_context *ssl )
      *     NOTE: This needs to be fixed, since like for
      *     handshake messages it is allowed to have
      *     multiple alerts witin a single record.
+     *     Internal reference IOTSSL-1321.
      *
      * (3) Change cipher spec:
      *     Consume whole record content, in_msglen = 0.
@@ -3791,6 +3792,15 @@ int mbedtls_ssl_read_record_layer( mbedtls_ssl_context *ssl )
     /* Case (1): Handshake messages */
     if( ssl->in_hslen != 0 )
     {
+        /* Hard assertion to be sure that no application data
+         * is in flight, as corrupting ssl->in_msglen during
+         * ssl->in_offt != NULL is fatal. */
+        if( ssl->in_offt != NULL )
+        {
+            MBEDTLS_SSL_DEBUG_MSG( 1, ( "should never happen" ) );
+            return( MBEDTLS_ERR_SSL_INTERNAL_ERROR );
+        }
+
         /*
          * Get next Handshake message in the current record
          */
@@ -3808,6 +3818,9 @@ int mbedtls_ssl_read_record_layer( mbedtls_ssl_context *ssl )
          *     Again, it's wrong for DTLS handshake fragmentation.
          *     The following check is therefore mandatory, and
          *     should not be treated as a silently corrected assertion.
+         *     Additionally, ssl->in_hslen might be arbitrarily out of
+         *     bounds after handling a DTLS message with an unexpected
+         *     sequence number, see mbedtls_ssl_prepare_handshake_record.
          */
         if( ssl->in_hslen < ssl->in_msglen )
         {